Cuánto tarda crear una app: plazos reales por etapa

Después del precio de una app, la pregunta que más escucho de los fundadores es: “¿en cuánto tiempo estará lista la app?”. Casi siempre llega con una fecha en la cabeza. Un evento, una ronda de inversión, la temporada de ventas. Y casi siempre la fecha se eligió antes de que alguien mirara lo que la app tiene que hacer.

El plazo de una app no es un número fijo. Es la suma de etapas, y algunas ni siquiera dependen de quien construye. En esta guía muestro cuánto tarda el mercado, qué pasa en cada etapa, los plazos de las tiendas que no controlas y qué acorta de verdad el calendario.

Cuánto tarda crear una app, según el mercado

La referencia pública más usada es la guía de apps de Clutch, plataforma que reúne reseñas verificadas de clientes de empresas de desarrollo. En la versión actualizada el 21 de septiembre de 2026, Clutch dice que un proyecto de app tarda, en promedio, unos 11 meses.

La misma página hace la salvedad que importa: algunas apps están listas en pocas semanas, otras tardan meses o incluso años. Según Clutch, el plazo depende de la complejidad de la app y del tamaño del equipo. Cuantas más funcionalidades, más horas de trabajo.

Lee el promedio como mercado, no como meta. Mezcla apps simples con productos enormes, de varios países. Lo que define el plazo de tu app es el tamaño de la primera versión, y ese tamaño lo decides tú.

Las 5 etapas de una app y qué pesa en cada una

Clutch enumera las fases del ciclo de una app: descubrimiento, planificación, diseño, desarrollo, pruebas, lanzamiento y mantenimiento. Para quien va a contratar, se pueden agrupar en cinco etapas.

1. Diagnóstico

Es donde se decide qué entra en la primera versión. Quién usa la app, qué tarea resuelve, con qué sistemas se conecta. Un diagnóstico corto y bien hecho ahorra semanas más adelante. Un diagnóstico salteado se vuelve retrabajo en medio del desarrollo.

2. Diseño

Flujos, pantallas y prototipo navegable. El plazo aquí depende menos del número de pantallas y más de cuántas personas deben aprobar. Una decisión parada diez días en el escritorio de un socio cuesta diez días de calendario.

3. Desarrollo

Es la etapa más larga. App, back-end y panel de administración, que casi siempre existe aunque nadie hable de él. Cada perfil de usuario y cada integración suman tiempo aquí.

4. Pruebas

Pruebas en equipos reales, iPhone y Android, con pantalla pequeña, mala conexión y poca batería. Corregir lo que aparece. Probar de nuevo. Esta etapa se reduce cuando las pruebas ocurren durante el desarrollo, y no solo al final.

5. Revisión de tiendas

La app lista todavía tiene que ser aprobada por Apple y Google. Es la única etapa en la que el plazo no depende de ti ni de tu proveedor, por eso merece una sección propia.

Revisión de Apple y prueba cerrada de Google: el plazo que no controlas

En la App Store, la página de App Review de Apple dice que la revisión funciona todo el día y suele evaluar al menos el 50% de los envíos en menos de 24 horas y el 90% en menos de 48 horas. La propia Apple advierte que un envío incompleto puede retrasar la revisión o ser rechazado. Existe la opción de pedir una revisión acelerada, por ejemplo para corregir un error crítico o lanzar junto con un evento, pero sin plazo garantizado.

En Google Play, la regla que más sorprende a los fundadores es otra. Según la ayuda de Play Console, las cuentas personales de desarrollador creadas después del 13 de noviembre de 2023 deben hacer una prueba cerrada con al menos 12 testers inscritos durante 14 días seguidos antes de publicar. El tester que sale antes de los 14 días no cuenta. Solo después se puede pedir acceso a producción, y esa revisión “usually takes seven days or less” (suele tardar siete días o menos), según Google.

Además, la página Publish your app advierte que algunas apps pasan por una revisión extendida, que puede llegar a 7 días o más en casos excepcionales.

Súmalo todo: una cuenta personal nueva en Google Play puede necesitar tres semanas entre la app lista y la app en la tienda. Eso tiene que estar en el cronograma desde el primer día, no descubrirse la semana del lanzamiento.

Qué hace que una app tarde más

Los retrasos se repiten de un proyecto a otro. Los más comunes:

• Alcance que crece a mitad de camino. Cada “solo una pantalla más” tiene flujo, regla y prueba. Sumadas, se vuelven meses.
• Integraciones con sistemas antiguos. ERP sin documentación, API inestable, entorno de pruebas que no existe. Es donde más se escapa el calendario.
• Muchos perfiles de usuario. Cliente, profesional y administrador son casi tres apps en una.
• Aprobación lenta. Contenido, textos y decisiones que dependen de varias personas de tu empresa.
• Cuentas de tiendas abiertas tarde. El registro en Apple y Google, los datos de la empresa y la prueba cerrada deberían empezar junto con el desarrollo.
• Rechazo en la tienda. Política de privacidad ausente, login que el revisor no puede probar, información incompleta. Cada reenvío es una nueva espera.

Fíjate que casi ninguno de estos puntos es “programar lento”. El tiempo se pierde en decisiones, dependencias y reglas de terceros.

Cómo acortar el plazo: recortar alcance, no calidad

Pedirle al equipo que trabaje más rápido rara vez funciona. Lo que acorta el plazo de verdad es reducir lo que debe estar listo en la primera versión. Escribí sobre este método en recortar alcance para llegar a la fecha.

En la práctica, funciona así:

1. Elige la única tarea que la app debe resolver bien en el lanzamiento. El resto va a una lista de próximas versiones.
2. Empieza con menos perfiles de usuario. Si el administrador puede operar desde un panel web simple, la app queda más pequeña.
3. Pospón las integraciones que no frenan la operación. Una exportación manual durante algunas semanas cuesta menos que un mes de retraso.
4. Usa un solo código para iOS y Android cuando la app no exige recursos muy específicos del equipo. Conviene entender la diferencia entre app nativa, híbrida o PWA.
5. Abre pronto las cuentas de las tiendas y la prueba cerrada, para que las dos semanas de Google corran en paralelo al desarrollo.
6. Define quién aprueba qué y en cuántos días. Una persona con poder de decisión vale más que un comité.

Una app más pequeña que sale pronto empieza a generar datos de uso reales. Y son esos datos los que dicen qué construir en la segunda versión, no la lista de deseos del inicio del proyecto.

Cómo lo hacemos en el Studio

En el Studio, el plazo queda por escrito en el contrato, junto con el precio cerrado después del diagnóstico. Antes de cualquier fecha, definimos qué entra y qué queda fuera de la primera versión. El equipo de desarrollo es nuestro, y usamos Claude Code y Figma en el diseño y el build. El código, los archivos y los accesos, incluidas las cuentas de las tiendas, quedan a nombre del cliente.

Dos casos muestran lo que pasa cuando el alcance cabe en la fecha. AI Vou Eu, un SaaS de turismo con IA, salió en línea en 4 semanas con el Studio. LCX, empresa de turismo con operación en más de 10 países de Sudamérica, tenía un sistema por país y pasó a tener uno solo, en línea en 29 días.

Y todo producto sale con un agente de IA que corre a diario, señala fallas, sugiere mejoras y verifica que los datos tengan sentido. Así, la segunda versión empieza con información, no con suposiciones.

Si tienes una fecha y quieres saber qué cabe en ella, el desarrollo de apps del Studio empieza por ese diagnóstico.