En resumen: el plazo de una app a medida depende de cuántos flujos, roles e integraciones tenga, así que nadie serio lo da antes de entender la operación. Lo que sí se puede asegurar es el ritmo: en V3XRA hay un prototipo navegable de las pantallas en días y después una entrega usable en producción cada dos semanas. Como referencia, un proyecto con varias integraciones suele llevar de tres a ocho semanas.
¿Por qué no hay un plazo estándar?
Por la misma razón que no hay un precio de lista: "una app de pedidos" puede ser una pantalla con un formulario o un sistema con tres tipos de usuario, pagos, entregas programadas y un cierre mensual que se arma solo. Las dos se describen con la misma frase y no se parecen en nada por dentro.
Quien te da un plazo por teléfono está estimando una plantilla, o va a extender el plazo después. Lo que sí se puede hacer antes de cotizar es entender qué mueve el número. Son las mismas variables que mueven el precio, que están explicadas en cuánto cuesta una app a medida: pantallas y flujos, roles y permisos, integraciones, y si hace falta versión móvil.
¿Cuáles son las etapas de un desarrollo a medida?
En V3XRA el orden es siempre el mismo, aunque el plazo total cambie.
1. Diagnóstico
Una reunión para entender el cuello de botella real: qué se hace hoy, quién lo hace, dónde se pierde tiempo o plata. Salís con un documento de alcance y un número, aunque no sigas con nosotros. No se cobra.
2. Prototipo navegable
En días ves las pantallas funcionando: podés hacer clic, navegar, mostrárselas a tu equipo. Todavía no hay base de datos ni backend. Es la etapa en la que cambiar de opinión es más barato, porque cambiar una pantalla cuesta una reunión. No se escribe backend hasta que lo aprobás.
3. Entregas cada dos semanas
Con el prototipo aprobado, empieza el desarrollo. Cada dos semanas hay algo usable en producción: no una presentación, algo que se puede usar. Si hay un desvío, se ve a los quince días y no al final del proyecto.
4. Traspaso
El repositorio, la infraestructura y la documentación quedan a nombre de tu empresa. Podés seguir con nosotros, con tu equipo o con otro estudio.
¿Por qué entregar cada dos semanas y no todo al final?
Porque el riesgo más grande de un desarrollo no es que tarde, sino que al final no sea lo que necesitabas. Un proyecto que desaparece tres meses y vuelve con una app terminada concentra todo ese riesgo en un solo día: si algo se entendió mal, se descubre cuando ya está construido encima.
Con entregas cada dos semanas pasan tres cosas. Un desvío se ve a los quince días, cuando corregirlo es barato. Tu equipo empieza a usar partes de la app antes del final, y ese uso real ordena lo que viene. Y vos sabés en todo momento en qué estado está el proyecto, sin depender de un informe: entrás y lo usás.
El plazo total no cambia por entregar por etapas. Lo que cambia es cuánto de ese plazo pasás sin ver nada, que en este esquema es casi cero.
¿Qué alarga un desarrollo?
Casi nunca es el código. Lo que alarga un proyecto, en orden de frecuencia:
- Cambios tardíos. Un cambio que se pide cuando ya están conectados la base de datos, los permisos y las pantallas cuesta semanas. El mismo cambio en el prototipo costaba una reunión. Cambios va a haber siempre; lo que se puede elegir es en qué momento salen baratos.
- Accesos que nadie pidió a tiempo. Integrar con Mercado Pago, WhatsApp, tu ERP o tu facturador requiere credenciales, cuentas verificadas o permisos de un tercero. Si eso se pide cuando ya hace falta, el proyecto espera.
- Información que no llega. Catálogos, precios, reglas de negocio que viven en la cabeza de una persona. Si no están escritos, hay que relevarlos.
- Alcance que crece sin decidirlo. "Ya que estamos, agreguemos…" Cada agregado es razonable; la suma no.
- Aprobaciones que dependen de alguien que no está. Cuando la persona que decide no participa de las revisiones, cada entrega espera su visto bueno.
¿Cómo se acorta el plazo?
No apurando el desarrollo, sino ordenando el alcance:
- Arrancar por el flujo que más duele. Si los pedidos se pierden en un chat, empezar por los pedidos, no por el panel de estadísticas.
- Salir con una primera versión. Publicar lo esencial y sumar lo demás en las entregas siguientes, con el uso real como guía.
- Pedir los accesos el primer día. Las cuentas de pago, el número de WhatsApp verificado, las credenciales del sistema que hay que integrar.
- Engancharse a lo que ya existe. Si ya tenés una base de datos o un sistema andando, conectarse a eso en vez de reemplazarlo ahorra tiempo y riesgo.
- Decidir en el prototipo. Todo lo que se resuelve antes del backend no se rehace después.
¿Cuánto tardaron apps reales?
No publicamos plazos por proyecto, pero sí publicamos lo que tiene adentro cada app, que es lo que define cuánto tarda:
- La app de pedidos de KUKUI: tres roles (empleado, empresa y marca), un catálogo de 229 productos, pago individual por Mercado Pago, pedido recurrente, bonificación por escalones y el consolidado mensual que se arma solo. Pocas pantallas y muchos flujos.
- El CRM de Digital View: un panel por cliente con aislamiento a nivel de base de datos, leads que entran solos desde Meta por webhook, métricas sincronizadas y quince secciones. Muchos roles e integraciones.
Las dos salieron del mismo proceso: diagnóstico, prototipo y entregas cada dos semanas.
¿Web o móvil cambia el plazo?
Sí. Una app web se usa desde el celular sin instalar nada y para la mayoría de las operaciones alcanza. Una app móvil hace falta cuando el equipo trabaja sin señal, necesita la cámara o tiene que recibir notificaciones. Hacemos Android y iOS desde una sola base de código, pero igual es una plataforma más que diseñar, probar y publicar en las tiendas. App web o app móvil explica cuándo conviene cada una.
¿Y si la app lleva inteligencia artificial?
Depende de dónde entre. Un agente de IA que atiende por WhatsApp o en el chat de la web suele estar andando en una a dos semanas. Si la IA es una función dentro de la app, como cargar un remito con una foto o detectar un pedido raro antes de que se despache, se planifica como una entrega más dentro del mismo calendario. Agente de IA o chatbot ayuda a definir qué tipo de IA necesitás.
¿Qué pedir por escrito sobre los plazos?
- Las etapas y qué se entrega en cada una, no sólo la fecha final.
- Cuándo ves el prototipo y cuándo la primera versión usable.
- Qué necesitan de vos y para cuándo: accesos, contenido, aprobaciones.
- Qué pasa con los cambios: en qué etapa salen baratos y cómo se cotizan después.
Qué preguntar antes de contratar un desarrollo a medida cubre el resto de lo que tiene que quedar en el papel, y en desarrollo de apps a medida está cómo trabajamos en V3XRA, con el diagnóstico sin cargo.
Preguntas frecuentes
El plazo total sale del alcance. Lo que no cambia es el orden. En días tenés un prototipo navegable de las pantallas, y después una entrega usable en producción cada dos semanas. Como referencia, un proyecto con varias integraciones suele llevar de tres a ocho semanas.
Primero ves el prototipo navegable de las pantallas, antes de que se escriba el backend. Después, cada dos semanas hay algo usable en producción. No hay un tramo largo en el que no puedas ver nada.
Los cambios tardíos y las esperas. Cambiar una pantalla cuando todavía es prototipo cuesta una reunión; cambiarla con la base de datos y los permisos ya conectados cuesta semanas. Y una integración que depende de accesos o credenciales que nadie pidió a tiempo frena todo lo que viene detrás.
Sí, y suele ser lo recomendable. Se arranca por el flujo que más impacto tiene y se publica eso primero. Lo demás entra en las entregas siguientes, ya con el uso real como guía.