Una app sencilla tarda entre 6 y 12 semanas; una app corporativa para iOS y Android, entre 3 y 5 meses; y una plataforma a medida, de 6 a 12 meses. Escribir código ocupa apenas la mitad de ese tiempo: el resto se va en descubrimiento, diseño, pruebas en dispositivos reales y revisión de tienda.
Casi ninguna propuesta arranca con esa cifra. Pregunte plazos en cinco agencias y va a recibir cinco versiones de “depende del alcance”, que es cierto pero inútil cuando usted necesita planear una fecha de lanzamiento, una campaña o una junta directiva. Esta guía abre el cronograma fase por fase, con semanas concretas, para que pueda leer cualquier propuesta y saber si el plazo prometido es realista o es una cifra puesta para ganar el contrato.
Cuánto tarda una app según el tipo de proyecto
Este es el cronograma por fases de los cinco tipos de proyecto más comunes en Colombia. Los plazos asumen un equipo dedicado, decisiones del cliente en menos de 48 horas y alcance congelado después del descubrimiento. Los valores en pesos son rangos de referencia del mercado colombiano, no tarifas de nadie, y aparecen solo para que compare plazo contra inversión.
| Tipo de proyecto | Descubrimiento | Diseño UX/UI | Desarrollo | QA + beta | Tienda | Total | Referencia (COP) |
|---|---|---|---|---|---|---|---|
| PWA (instalable sin tiendas) | 1 sem | 1 – 2 sem | 2 – 4 sem | 1 sem | 0 | 4 – 8 sem | $8.000.000 – $25.000.000 |
| MVP (3–6 pantallas, una plataforma) | 1 – 2 sem | 1 – 2 sem | 3 – 6 sem | 1 – 2 sem | 1 sem | 6 – 12 sem | $12.000.000 – $28.000.000 |
| App corporativa (login, catálogo, push) | 2 – 3 sem | 3 – 4 sem | 6 – 10 sem | 2 – 3 sem | 1 sem | 14 – 21 sem | $30.000.000 – $70.000.000 |
| App de e‑commerce (carrito, pagos) | 3 – 4 sem | 4 – 5 sem | 9 – 16 sem | 3 – 4 sem | 1 – 2 sem | 20 – 31 sem | $55.000.000 – $120.000.000 |
| Plataforma a medida (IA, tiempo real, ERP) | 4 – 6 sem | 5 – 8 sem | 14 – 30 sem | 4 – 6 sem | 1 – 2 sem | 28 – 52 sem | $120.000.000 – $350.000.000 |
Tres lecturas que salen de esa tabla. Primero: el desarrollo rara vez pasa del 60% del calendario, así que cualquier propuesta que le cotice solo horas de programación le está escondiendo el 40% restante del tiempo. Segundo: duplicar pantallas no duplica el plazo, pero duplicar integraciones sí; una app de 20 pantallas que solo muestra contenido se entrega antes que una de 8 que cobra con tarjeta. Tercero: la fila de la PWA no tiene semanas de tienda porque no pasa por revisión, y esa sola diferencia explica por qué a veces conviene elegir entre app nativa, híbrida o PWA antes de mirar presupuestos.
Las seis fases del desarrollo de una app, una por una
1. Descubrimiento: 1 a 6 semanas
El discovery es donde se decide qué NO va en la versión 1. Se levantan los flujos de usuario, se define el modelo de datos, se listan las integraciones externas (pasarela de pago, ERP, WhatsApp, facturación electrónica) y se arma el backlog priorizado. Termina con un documento de alcance firmado y un cronograma con fechas.
Es la fase que más clientes quieren saltarse y la que más plazo ahorra. En la práctica, una semana de descubrimiento bien hecha suele evitar varias semanas de reconstrucción más adelante. Si la propuesta que recibió no incluye descubrimiento, el proyecto va a descubrir igual, solo que a mitad de camino y con el código ya escrito.
2. Diseño UX/UI: 1 a 8 semanas
Aquí se produce el flujo navegable de todas las pantallas, el sistema de diseño (colores, tipografías, componentes) y los estados que nadie recuerda pedir: vacío, cargando, sin conexión, error de pago, sesión vencida. Esos estados suelen sumar una porción larga del total de pantallas de una app real, y por eso el conteo de “pantallas” de una propuesta casi siempre se queda corto.
El diseño puede arrancar en paralelo con la arquitectura técnica, y ahí se recuperan una o dos semanas. Lo que no se puede es empezar a programar pantallas que todavía se están discutiendo: en la práctica, un cambio de diseño hecho cuando ya hay código cuesta varias veces más tiempo que el mismo cambio hecho en la etapa de bocetos, porque toca rehacer pantalla, lógica y pruebas.
3. Desarrollo por sprints: 50% a 60% del cronograma
El desarrollo serio se organiza en sprints de dos semanas. Al final de cada sprint usted debe recibir una app instalable en su propio teléfono, no un video ni una captura de pantalla. Si al terminar el tercer sprint todavía no ha podido tocar nada, el proyecto ya está en riesgo aunque el informe diga que va al día.
Un orden que funciona: primero el esqueleto de navegación y la autenticación, después el flujo que genera el valor principal, luego las integraciones externas y al final los extras. Las integraciones con terceros van de terceras a propósito: son la parte del cronograma que usted no controla, y necesita margen de reacción cuando la pasarela de pago responda en cuatro días hábiles en lugar de uno.
4. QA y pruebas en dispositivos reales: 1 a 6 semanas
El QA/testing no es “probar la app al final”. Es un ciclo de encontrar, corregir y volver a verificar sobre teléfonos físicos, no solo simuladores. En Colombia el parque de dispositivos Android es muy fragmentado: hay que probar en gama baja con poca memoria, en pantallas pequeñas y con conexión intermitente, porque ahí es donde vive buena parte de los usuarios.
Regla práctica: presupueste una semana de QA por cada cuatro de desarrollo. Si el cronograma que le entregaron deja tres días de pruebas para un proyecto de cuatro meses, el plazo no incluye QA: incluye la esperanza de que no haya errores.
5. Beta cerrada con TestFlight y Google Play: 1 a 3 semanas
Antes de publicar, la app se distribuye a un grupo real de usuarios. En iOS se hace con TestFlight; en Android, con las pistas de prueba interna y cerrada de Google Play. Aquí aparecen los problemas que ningún equipo técnico detecta: gente que no entiende un botón, que abandona en el registro, que instala la app en un modelo que nadie probó.
Hay un detalle que descuadra cronogramas completos: Google Play mantiene, para las cuentas de desarrollador personales nuevas, un requisito de pruebas cerradas con testers reales durante varias semanas antes de habilitar la publicación en producción. Las condiciones exactas cambian con frecuencia, así que conviene confirmarlas en la consola antes de comprometer una fecha; si abre la cuenta el día del lanzamiento, ese reloj apenas empieza a correr. Los demás requisitos para publicar en App Store y Google Play también conviene revisarlos en la semana 1, no en la última.
6. Publicación y revisión de tienda: 1 día a 2 semanas
La revisión de App Store suele resolverse en uno o dos días. El riesgo no es el tiempo de espera, es el rechazo. Un rechazo por permisos mal justificados, cuenta de prueba que no funciona o política de privacidad ausente le cuesta el ciclo completo otra vez.
| Concepto | Plazo que se ve con más frecuencia | Referencia de costo (COP) |
|---|---|---|
| Revisión de App Store (Apple) | 1 – 2 días hábiles | Cuenta de desarrollador: ~$400.000 al año, según TRM |
| Revisión de Google Play (cuenta establecida) | 1 – 7 días | Cuenta de desarrollador: ~$100.000 pago único, según TRM |
| Google Play, cuenta personal nueva | Semanas adicionales por el periodo de pruebas cerradas | Incluido en el pago único |
| Reenvío después de un rechazo | Reinicia el ciclo completo | $0 en tarifas, pero cuesta días de calendario |
Los valores de la tabla son referencias aproximadas: dependen de la TRM del día y de las tarifas y políticas vigentes de cada tienda, que cambian sin aviso. Ninguna tienda garantiza tiempos de revisión. Un dato que ahorra sustos: las cuentas de desarrollador se pueden crear desde la semana 1 del proyecto y la verificación de identidad puede tardar días. Crearlas temprano es la optimización de cronograma más barata que existe.
Qué retrasa de verdad un proyecto de app
Los proyectos rara vez se retrasan por código difícil. Se retrasan por decisiones que no llegan. Esta tabla estima el impacto de las causas más frecuentes y lo traduce a plata, usando como referencia el costo semanal de un equipo dedicado en el mercado colombiano.
| Causa del retraso | Semanas perdidas | Costo estimado (COP) |
|---|---|---|
| Cambios de alcance después de firmar (scope creep) | 2 – 8 | $5.000.000 – $30.000.000 |
| Contenido, textos, fotos o catálogo que no llegan | 1 – 4 | $2.500.000 – $15.000.000 |
| Aprobaciones lentas del cliente (más de 5 días por entrega) | 2 – 6 | $5.000.000 – $22.000.000 |
| Accesos e integraciones de terceros sin gestionar a tiempo | 1 – 5 | $2.500.000 – $18.000.000 |
| Rechazo en tienda por requisitos no revisados | 1 – 3 | $2.500.000 – $11.000.000 |
| Diseño aprobado a medias y reabierto en desarrollo | 2 – 5 | $5.000.000 – $18.000.000 |
| Backend o API del cliente que no está lista | 2 – 10 | $5.000.000 – $35.000.000 |
Los cálculos parten de un costo de equipo de referencia entre $2.500.000 y $3.500.000 COP por semana en proyectos tipo MVP, y más alto en proyectos grandes. No son tarifas de nadie: son órdenes de magnitud para que dimensione lo que cuesta una semana de silencio. El desglose completo de la inversión está en el análisis de precios reales de desarrollo de apps en Colombia.
Note el patrón: cinco de las siete causas dependen del cliente, no del proveedor. La velocidad con la que usted responde no es una cortesía, es una variable del cronograma con la misma fuerza que la complejidad técnica.
Cuánto influye el tamaño del equipo en el plazo
Un mismo alcance se entrega en tiempos muy distintos según quién lo ejecute. Estos son rangos de referencia del mercado colombiano para el mismo MVP descrito arriba, con las ventajas y los riesgos de cada figura.
| Quién ejecuta | Plazo del mismo MVP | Costo semanal de referencia (COP) | Riesgo principal |
|---|---|---|---|
| Freelance solo (full stack) | 14 – 20 sem | $1.200.000 – $2.200.000 | Cuello de botella único: si se enferma, el proyecto para |
| Dúo (desarrollo + diseño) | 10 – 14 sem | $2.000.000 – $3.000.000 | QA débil, sin proceso formal de pruebas |
| Equipo pequeño de agencia (3–4 personas) | 8 – 12 sem | $2.500.000 – $3.500.000 | Proyecto compartido con otros clientes |
| Célula dedicada (5+ personas) | 6 – 9 sem | $4.000.000 – $7.000.000 | Costo alto si el alcance no está congelado |
La lectura importante es que agregar gente no reduce el plazo de forma proporcional. Duplicar el equipo puede recortar un 30% o 40% del tiempo de desarrollo, no la mitad, porque el descubrimiento, la aprobación del diseño y la revisión de tienda no se pueden repartir entre más personas. Y por debajo de cierto punto agregar gente lo empeora: cada persona nueva consume tiempo de las que ya estaban.
Por qué casi ninguna agencia publica plazos
Hay tres razones, y solo una es legítima.
- La legítima: sin alcance definido, cualquier número es una mentira estadística. Una “app de domicilios” puede ser 8 semanas o 10 meses según si incluye seguimiento en tiempo real, liquidación a repartidores y facturación electrónica.
- La comercial: un plazo publicado es un compromiso que el cliente puede reclamar. Es más cómodo negociarlo cuando el prospecto ya está emocionado con la propuesta.
- La incómoda: muchas propuestas están calculadas solo sobre horas de programación. Cuando se suman descubrimiento, diseño, QA, beta y tienda, el plazo real puede crecer bastante más de la mitad frente a esa cuenta inicial, y ese número asusta en una primera reunión.
La forma de neutralizar las tres es pedir el cronograma desglosado por fases, con entregables verificables por fase. Si el proveedor no lo puede armar, es porque no lo tiene.
Cronograma de ejemplo: un MVP en 12 semanas
Así se ve, semana a semana, un MVP con alcance controlado. Sirve como plantilla para contrastar cualquier propuesta que reciba.
| Semanas | Qué pasa | Qué debe recibir usted |
|---|---|---|
| 1 – 2 | Discovery, flujos, backlog priorizado, apertura de cuentas de tienda | Documento de alcance firmado y cronograma con fechas |
| 3 – 4 | Diseño UX/UI, sistema de diseño, estados de error | Prototipo navegable de todas las pantallas |
| 5 – 6 | Sprint 1: navegación, autenticación, base de datos | App instalable con el esqueleto funcionando |
| 7 – 8 | Sprint 2: flujo principal completo | App instalable donde ya se hace la tarea central |
| 9 – 10 | Sprint 3: integraciones, notificaciones, analítica | App instalable en condiciones cercanas a producción |
| 11 | QA en dispositivos reales y corrección de errores | Reporte de pruebas y lista de errores cerrados |
| 12 | Beta con TestFlight y pistas de Play, envío a tiendas | App publicada y accesos de administración entregados |
Si su propuesta comprime esto en seis semanas, algo se está eliminando: casi siempre el descubrimiento y el QA, que son justo las dos fases cuya ausencia se paga después. Cómo recortar sin romper el producto es exactamente el problema que resuelve definir bien el alcance típico de un MVP.
¿La IA y el no-code acortan los tiempos de verdad?
Sí, pero no donde la gente cree. En 2026 la asistencia con IA acelera de forma real la escritura de código repetitivo, las pruebas unitarias, la documentación y los textos de las pantallas. Una estimación prudente es que recorta entre el 15% y el 30% de la fase de desarrollo, que a su vez es la mitad del cronograma: en un MVP de 12 semanas, hablamos de una o dos semanas menos, no de la mitad.
Lo que la IA no acorta: las decisiones de negocio del descubrimiento, la aprobación del diseño, las pruebas en dispositivos reales, la verificación de la cuenta de desarrollador y la revisión de tienda. Esas fases dependen de personas y de terceros, y son inelásticas.
El no-code es distinto. Sirve muy bien para validar una idea en dos o tres semanas y para herramientas internas. Empieza a fallar cuando el producto necesita lógica de negocio propia, rendimiento en gama baja, funciones nativas del teléfono o control del costo por usuario. El patrón sensato es validar en no-code y construir en código lo que ya demostró demanda.
El cronograma no termina el día que publica
Publicar es un hito, no el final. Reserve tiempo para tres cosas que llegan siempre después del lanzamiento y que casi ninguna propuesta incluye en el plazo original:
- Primera actualización correctiva: de 1 a 3 semanas después de publicar. Los usuarios reales encuentran en dos días lo que el equipo no vio en dos meses, y esa versión 1.0.1 hay que programarla, probarla y volverla a enviar a revisión.
- Mantenimiento evolutivo: las tiendas actualizan periódicamente sus requisitos técnicos mínimos y las librerías de terceros quedan obsoletas. Una app sin mantenimiento no se queda igual: se rompe sola con el paso de los meses.
- Versión 1.1 con lo que quedó fuera: todo lo que sacó del alcance para llegar a la fecha vuelve a la mesa. Planee un ciclo de 4 a 8 semanas, con su propio descubrimiento corto.
Un presupuesto anual de mantenimiento entre el 15% y el 25% de la inversión inicial es el rango de referencia con el que conviene planear: una app de $40.000.000 COP implica prever entre $6.000.000 y $10.000.000 COP al año solo para mantenerla viva y publicable.
Cómo blindar el cronograma antes de firmar
Seis exigencias concretas que puede poner en la propuesta y que cambian el resultado más que cualquier metodología:
- Cronograma por fases con fechas, no un plazo global de “cuatro meses”.
- Una app instalable al final de cada sprint, en su teléfono, sin excepciones.
- Alcance congelado tras el descubrimiento, con un procedimiento escrito para los cambios: cada uno cotiza tiempo y dinero antes de entrar.
- Un único responsable de decisiones de su lado y un compromiso de respuesta en 48 horas.
- Cuentas de desarrollador creadas y verificadas en la semana 1, no en la última.
- Despliegue por fases en el lanzamiento: publicar a una fracción de los usuarios, medir errores 48 horas y ampliar. Agrega dos o tres días al calendario y evita que un fallo llegue a toda la base de usuarios de golpe.
Trabajo en marketing digital y desarrollo desde 2009, soy Google Partner certificado y tengo 4.9 estrellas con 30 reseñas en Google. Tengo apps propias publicadas en las tiendas —Chately, Rankiamos y VialKy—, así que el cronograma de este artículo está armado desde la práctica de recorrer esas fases, no desde una plantilla comercial. Atiendo Bogotá, Medellín, Cali, Barranquilla, Bucaramanga y Cúcuta, y al resto de Colombia en remoto. Si quiere un cronograma aterrizado a su caso, con fases, fechas y entregables, revise el servicio de desarrollo de apps o escríbame por WhatsApp al +57 300 208 1105 con la lista de flujos que necesita. Con esa lista en la mano, armar un cronograma serio toma una reunión, no dos semanas.
