Alguien pregunta cuánto se tarda en desarrollar una app, le contestan «cuatro meses», y la app sale a los seis y medio. Cuando reconstruyes lo que pasó, casi nunca encuentras a un equipo programando más despacio de lo previsto. Encuentras dos semanas esperando a que alguien aprobara unos diseños, catorce días de pruebas cerradas obligatorias en Google Play que nadie puso en el calendario y una integración parada esperando credenciales del ERP.
En Docastix damos plazos de desarrollo de apps móviles con hitos y con una lista escrita de qué necesitamos de tu lado y para cuándo. El plazo que firma un proveedor cubre solo una parte del calendario que tú vas a vivir, y conviene tener el resto sobre la mesa desde el principio.
Respuesta rápida: ¿cuánto se tarda en desarrollar una app?
Una app sencilla se construye en 2-3 meses, una app media en 4-6 meses y una app compleja en 7-12 meses o más. Son las cifras de cualquier presupuesto serio y son correctas, pero miden el trabajo del equipo, no el calendario de tu proyecto: entre «el equipo ha terminado» y «mi app está descargable» hay trámites y requisitos con fecha que no dependen de nadie a quien puedas pagar.
| Tipo de app | Trabajo del equipo | Lo que añaden las tiendas y el papeleo | Calendario realista de punta a punta |
|---|---|---|---|
| Sencilla: contenido, formularios, login | 2-3 meses | De días a 3-4 semanas si la cuenta de Google Play es personal y nueva | 3-4 meses |
| Media: backend propio, cuentas, pagos | 4-6 meses | Lo anterior, más cuestionarios y declaraciones de ambas tiendas | 5-7 meses |
| Compleja: integraciones, varios roles, volumen | 7-12+ meses | Lo anterior, más algún requisito de plataforma con fecha | 8-13+ meses |
El desglose por fases y su peso sobre el presupuesto ya está en cuánto cuesta hacer una app; lo que falta ahí, y en casi todas las tablas de plazos, es la tercera columna. Y la última no incluye tus esperas internas.
Si te quedas con tres cifras: 12 testers durante 14 días seguidos para publicar con una cuenta personal nueva de Google Play, «siete días o menos» para que Google revise el acceso a producción y 4-6 meses de equipo para la app media española de unos 40.000 €.
Los tres relojes que deciden la fecha de tu app
El plazo de una app no lo decide el equipo de desarrollo: lo deciden tres relojes que corren a la vez.
El reloj del equipo es lo único que el proveedor controla, y paradójicamente es el que menos se desvía: es el único que alguien ha estimado con datos de proyectos anteriores.
El reloj del cliente son tus decisiones pendientes, validaciones, contenidos, accesos a sistemas y quién firma. Es el que más retrasa proyectos y el que nunca aparece en un Gantt: ningún proveedor se atreve a escribir «esperando al cliente: 11 días».
El reloj de terceros son las tiendas, la normativa y el software ajeno con el que te integras: ni se negocia ni se acelera con dinero.
De ahí la frase que resume el artículo: el proveedor te da un plazo sobre el primer reloj y tú vives los tres. Cuando un proyecto «se va tres meses», casi siempre es que los otros dos sumaron lo que nadie contó.
El reloj del equipo: qué se tarda de verdad en construirlo
Esta es la parte fácil, y por eso es la única de la que se habla. Un equipo con oficio estima la construcción con un error razonable porque las fases se parecen entre proyectos; el detalle de cada una está en el proceso de desarrollo de aplicaciones móviles. Lo que conviene entender es qué mueve ese reloj: decisiones tuyas tomadas casi siempre mirando solo el precio.
- Cuántas plataformas y con qué stack. Dos apps nativas son dos bases de código y dos ciclos de pruebas; una multiplataforma concentra el trabajo pero te ata al ritmo con el que ese framework se adapta a cada versión de sistema. Lo comparamos en nativo frente a multiplataforma.
- Si hay backend propio y cuántas integraciones. Consumir una API existente y construir servidor, base de datos, panel y cuentas no están en la misma escala. Y una API documentada, con entorno de pruebas e interlocutor técnico, es una semana; la misma API «que existe», sin documentación y con un contacto que responde los martes, es un mes.
- Pagos, suscripciones y datos personales. Cada uno añade flujos, casos de error, textos legales y pruebas de renovación y cancelación en los entornos de las tiendas.
- Offline de verdad. Que la app funcione sin cobertura y sincronice después es arquitectura, no una casilla. En Saher Connect fue el requisito central: más de 200 referencias de boquillas ISO consultables en un campo sin señal.
Este reloj tampoco es exacto, pero se desvía dentro de un margen conocido y tiene un responsable. Los otros dos no tienen dueño.
El reloj del cliente: el que nadie pone en el calendario
Aquí se pierden los proyectos, y aquí no entra casi nadie porque es incómodo.
Aprobar diseños. El equipo entrega un prototipo navegable el jueves y la respuesta llega doce días después: había que enseñárselo a marketing, marketing tenía dudas sobre el color de marca y el comercial estaba de viaje. Doce días que no salen en ninguna factura pero sí en la fecha de salida. Dos o tres rondas con un decisor lento son un mes.
Conseguir accesos a sistemas internos. El presupuesto dice «integración con tu ERP: 3 semanas». El equipo pide credenciales de un entorno de pruebas el día uno y aparecen a las cinco semanas, tras pasar por el proveedor del ERP, por seguridad interna y por un formulario. El trabajo sigue siendo de tres semanas; el hito se movió cinco.
Decidir el modelo de negocio. Suscripción o pago único, con prueba gratuita o sin ella, a qué precios y en qué mercados. Afecta a la arquitectura, a las fichas y a lo que hay que declarar en cada plataforma, así que decidirlo en la semana dieciséis cuesta mucho más que en la dos. Las opciones están en monetización de apps.
Entregar contenidos y textos legales. Política de privacidad, condiciones de uso, textos de ficha, capturas y traducciones suenan a último día, y a menudo son lo que bloquea el último día.
Tener a alguien que decida. Es el factor que más mueve la fecha. Un proyecto con un interlocutor con autoridad, disponible unas horas por semana y capaz de cerrar una discusión, avanza al ritmo del equipo. Uno donde cada decisión sube a un comité quincenal avanza al ritmo del comité.
Dos consecuencias. Si te ofrecen un plazo sin decirte qué necesitan de ti y para cuándo, ese plazo es una intención. Y el modelo de contrato importa: en precio cerrado tus retrasos empujan el proyecto contra el calendario de otros clientes y en bolsa de horas los pagas literalmente, como explicamos en precio cerrado vs bolsa de horas. Nuestra contramedida es poco glamurosa: una lista de dependencias del cliente con fecha, dueño con nombre y apellidos y consecuencia escrita si no llega. Puesta en una tabla, el problema se ve y se resuelve.
El reloj de las tiendas: catorce días que no puedes comprar
Casi nadie planifica este bloque, y aparece al final, con la fecha ya comunicada a comercial. Si publicas en Google Play con una cuenta de desarrollador personal creada después del 13 de noviembre de 2023, Google exige una prueba cerrada con al menos 12 testers inscritos de forma continua durante los 14 días previos a solicitar acceso a producción. Cada palabra cuesta días: doce personas, no dos; inscritas de forma continua, así que si una se sale a mitad el contador sufre; y catorce días naturales que empiezan cuando tienes una compilación estable, no al firmar.
Y ahí no acaba. Terminados los catorce días solicitas el acceso a producción, y esa solicitud se revisa aparte: Google dice que suele tardar siete días o menos y advierte de que puede alargarse. Total: tres semanas largas entre tener la app terminada y poder publicar.
El matiz honesto: esto no aplica a las cuentas de organización. De ahí la recomendación más rentable del artículo: abre la cuenta de empresa el primer día, no el último. Cuesta 25 € de pago único en Google y 99 € al año en Apple, e implica una verificación de identidad que también tarda. Es el trámite más barato y el que más plazo salva.
En Apple los bloqueos son otros: requisitos con fecha que condicionan la distribución. En la página de requisitos futuros de Apple están los dos que más afectan a un lanzamiento europeo: el estado de «trader» del DSA, obligatorio para distribuir en la Unión Europea, y el cuestionario actualizado de clasificación por edad, exigible en App Store Connect desde el 31 de enero de 2026. Ninguno es difícil, pero los dos requieren información de tu empresa.
Y una precisión que conviene tener clara antes de comprometer una fecha: lo que publican las tiendas son medias, no compromisos. Apple afirma que de media el 90% de los envíos se revisan en menos de 24 horas y Google habla de «siete días o menos» para el acceso a producción. Ninguna de las dos es una garantía que puedas reclamar, y ninguna cubre el caso que de verdad mueve la fecha: el rechazo. Un rechazo por una captura que no corresponde al producto, por una cuenta de demo que no funciona o por un texto de privacidad incompleto reinicia el contador, y dos rechazos encadenados son otra semana. Planifica con la media y deja margen para uno.
Por qué meter más gente no acorta el plazo
Cuando un proyecto va tarde, el instinto es pedir más personas. Casi nunca funciona.
Primero, hay trabajo secuencial por naturaleza: no puedes probar una pantalla que no existe ni integrar una API cuyo contrato de datos no está definido. Cuatro personas no diseñan el modelo de datos cuatro veces más rápido, se estorban.
Segundo, cada incorporación cuesta antes de rendir, y ese coste lo pagan quienes ya estaban, que son quienes explican. Y la comunicación crece más rápido que el equipo.
Tercero, y es el que más duele: el cuello de botella suele estar en el reloj del cliente. Si el proyecto espera una decisión sobre precios, dos desarrolladores más producen código pendiente de aprobación, no avance. La única palanca que acorta plazo es quitar alcance.
Qué se puede comprimir de verdad y qué no
Sí: recortar alcance. Es la palanca real. Menos pantallas, menos roles, menos casos límite en la versión uno. No es rendirse, es ordenar: sacar antes algo que funciona y aprender de usuarios reales vale más que sacar seis semanas después algo completo sin validar. El criterio está en producto mínimo viable y el plazo de esa primera versión, en cómo sacar un MVP en menos de 3 meses.
Sí: paralelizar lo paralelizable. Mientras se diseñan las pantallas de la fase dos se construye el backend de la fase uno. Exige el alcance de la fase uno cerrado: paralelizar sobre algo que cambia es rehacer trabajo.
Sí: adelantar lo administrativo. Cuentas de desarrollador, verificación de empresa, textos legales, cuestionarios de tienda y lista de testers no dependen de que haya código: hechos en la semana uno desaparecen del camino crítico; dejados para el final, son el camino crítico. Salir primero en una sola tienda también es una decisión de plazo defendible.
No: saltarse el control de calidad, comprar los catorce días de Google ni acelerar decisiones de negocio con recursos técnicos. Lo que ahorras probando menos lo devuelves en correcciones urgentes, reseñas de una estrella y republicaciones. Para la prueba cerrada no hay tarifa de urgencia, y si el modelo de precios no está decidido no hay nada que programar.
Un proyecto largo cruza cambios de requisitos a mitad
Cuanto más dura un proyecto, más probable es que cruce una fecha límite de plataforma que no existía cuando lo firmaste.
Desde el 28 de abril de 2026, Apple exige compilar con Xcode 26 y el SDK de iOS 26 —y equivalentes de iPadOS, tvOS, visionOS y watchOS 26— para subir cualquier binario a App Store Connect. Y desde el 31 de agosto de 2026, Google Play obliga a apuntar a Android 16 (API 36) en apps nuevas y actualizaciones, con prórroga hasta el 1 de noviembre de 2026.
Haz la cuenta con un proyecto de ocho meses: empieza en enero, publica en septiembre y cruza las dos fechas. Si el equipo trabajaba contra un SDK anterior porque «ya se actualizará al final», eso no es un trámite de una tarde: es una ronda completa de adaptación y pruebas en el peor momento.
La lectura para ti es simple: pregunta contra qué versiones se construye y qué pasa si sale un requisito nuevo a mitad. Un equipo al día absorbe estos cambios sin drama; uno que acumula deuda los convierte en semanas de retraso. Y el reloj no para al publicar: llega un ciclo de adaptaciones anuales con su propio coste, desglosado en cuánto cuesta mantener una app.
Cómo leer el plazo de un presupuesto sin que te la den
- Un plazo sin hitos intermedios. «Cinco meses» no es información. «Prototipo en la semana 4, versión instalable en la 10, candidata en la 18, publicación en la 21» sí lo es: a las cuatro semanas ya sabes si vais bien.
- Un plazo sin dependencias del cliente por escrito. Si no dice qué te van a pedir, cuándo y qué pasa si llega tarde, el proveedor asume que responderás en el día y tú, que la fecha es firme. Uno de los dos se llevará una sorpresa.
- «Entrega en X semanas» sin decir desde cuándo se cuenta. ¿Desde la firma, desde el pago inicial o desde que entregues accesos e identidad de marca? Entre esas fechas hay semanas.
- Un plazo que termina cuando termina el equipo. Si no incluye la publicación en ambas tiendas con sus trámites, está incompleto. Pregunta: esa fecha, ¿es «código terminado» o «descargable en la tienda»?
Añade dos preguntas que separan a un equipo con experiencia de uno sin ella: ¿a nombre de quién van a estar las cuentas de desarrollador y cuándo se abren? ¿Habéis contado los catorce días de prueba cerrada de Google Play? Si la respuesta a la segunda es «¿los qué?», ya sabes cuánto vale la fecha. Los demás criterios están en cómo elegir el mejor equipo para desarrollar tu app, y para una horquilla rápida tienes la calculadora de presupuesto.
Conclusión
La pregunta «cuánto se tarda en desarrollar una app» tiene una respuesta corta honesta —2-3 meses una sencilla, 4-6 una media, 7-12 o más una compleja— y otra más útil: eso mide el reloj del equipo, y tu proyecto corre tres. El tuyo depende de con qué rapidez decides, validas y entregas. El de las tiendas no lo controla nadie: se planifica con antelación, empezando por abrir las cuentas de desarrollador de empresa el primer día.
El que más veces hemos visto tumbar una fecha es el segundo, y es el único que puedes arreglar sin gastar un euro: nombra a alguien con autoridad para decidir y ponle fecha a cada cosa que el equipo necesita de tu lado. Si tienes una fecha objetivo y quieres saber si es realista antes de comprometerla, escríbenos en contacto: te decimos qué cabe, qué no y qué habría que recortar. Si no da, preferimos decírtelo antes de firmar.
Preguntas frecuentes
Entre 2 y 3 meses una app sencilla, entre 4 y 6 meses una app media con backend, cuentas y pagos, y de 7 a 12 meses o más una compleja. Esas cifras miden el trabajo del equipo: al calendario real hay que sumar los trámites de publicación y lo que tarde el cliente en decidir y validar.