Cuando un cliente se enfrenta por primera vez al desarrollo de software, la pregunta principal no suele ser «cuánto cuesta», sino «¿cómo se hace una app en realidad y qué recibo en cada paso?». Entender las fases no es simple curiosidad: es justo en el paso de una a otra donde los proyectos pierden tiempo, presupuesto y control. Si sabes qué debe entregar cada fase, puedes aceptar el trabajo con seguridad y no pagar nunca por humo.
Repasemos en orden las fases del desarrollo de una app móvil: qué pasa, cuánto dura, qué recibes y en qué fijarte como cliente. Es un mapa del proceso desde la primera reunión hasta las tiendas de apps y el mantenimiento posterior. Si solo estás explorando la idea, empieza por nuestra guía sobre cómo crear una app móvil y vuelve aquí para los detalles del proceso.
Fase 1. Análisis y especificación
Qué pasa. El equipo desmenuza tu problema de negocio: quién es el usuario, qué recorrido sigue, qué funciones van en la primera versión y cuáles pueden esperar. Describe los escenarios, redacta los requisitos, esboza un mapa de pantallas y lo recoge todo en una especificación.
Cuánto dura. De 3–5 días para un MVP a 2–3 semanas para un producto complejo.
Qué recibes. Una especificación con la lista de funciones y escenarios, un mapa de pantallas y una estimación de plazo y presupuesto. Es el documento con el que luego se aceptará el trabajo.
En qué fijarte. No aceptes empezar sin una especificación por escrito. Un vago «hazlo como el de la competencia» es la principal causa de discusiones y retrabajo. Explicamos cómo describir tu proyecto para recibir una estimación precisa en nuestro artículo sobre cómo redactar la especificación de una app. Esta fase parece papeleo, pero es la que más dinero ahorra después.
Una técnica útil en el análisis es dividir las funciones en «imprescindible en la primera versión» y «más adelante». Cuanto menos metas en la primera versión, antes lanzas y antes recibes opiniones reales de los usuarios en lugar de suposiciones. Si se mira con honestidad, la mayoría de las funciones «imprescindibles» resultan ser simplemente deseables, y pueden esperar sin problema a la segunda versión.
Fase 2. Diseño UX/UI
Qué pasa. Primero va la UX, la lógica y la estructura de las pantallas: dónde va cada botón, en qué orden se suceden los pasos, cómo llega el usuario a su objetivo con el menor número de toques. Después, encima, la UI: la capa visual de colores, tipografías, iconos y estilo de marca. El diseñador crea maquetas de cada pantalla en dos o tres estados: vacía, con datos y con error.
Cuánto dura. De 1 semana para un MVP a 4–6 semanas para una app con decenas de pantallas.
Qué recibes. Maquetas de diseño de cada pantalla en Figma y un UI kit, un conjunto de elementos reutilizables que mantiene la app coherente.
En qué fijarte. Comprueba que el diseño funciona de verdad en un móvil: los botones deben quedar al alcance del pulgar, el texto debe leerse en una pantalla pequeña y la acción principal debe verse a la primera. Ten en cuenta que iOS y Android siguen guías distintas, las Human Interface Guidelines y Material Design: los mismos elementos se ven y se comportan de forma diferente, y un buen diseñador lo tiene en cuenta. Aprueba las maquetas con cuidado: rehacer un diseño es barato, pero adaptar código terminado a un diseño nuevo sale caro.
Fase 3. Prototipo
Qué pasa. Las maquetas se convierten en un prototipo clicable que te permite «recorrer» un escenario como si fuera la app real, pulsando botones y pasando de una pantalla a otra. Todo sin una sola línea de código.
Cuánto dura. 2–5 días, normalmente solapados con el final de la fase de diseño.
Qué recibes. Un prototipo interactivo con el que tú y el equipo recorréis los escenarios clave: registro, acción principal, pago.
En qué fijarte. Es el último momento barato para cambiar la lógica. Recorre el prototipo como lo haría un usuario real y caza todo lo que resulte incómodo o ilógico. Aquí cualquier cambio lleva minutos; sobre código terminado lleva días y miles de euros. No te saltes esta fase para ahorrar.
Fase 4. Desarrollo por sprints
Qué pasa. El equipo escribe el código. El trabajo se organiza en sprints, ciclos cortos de 1–2 semanas, y al final de cada uno recibes una versión que funciona con funciones nuevas. Se construyen dos partes en paralelo: el frontend, lo que el usuario ve en la pantalla, y el backend, que abarca la lógica del servidor, la base de datos, la autenticación y los pagos.
Cuánto dura. Es la fase más larga: de 2–3 semanas para un MVP a varios meses para un producto complejo.
Qué recibes. Una app que funciona y que puedes instalar y probar después de cada sprint.
En qué fijarte. Exige una demo al final de cada sprint: es tu principal herramienta de control. Ves el avance cada dos semanas en lugar de una sola vez «al final», cuando ya es tarde para cambiar nada. Pregunta por el stack tecnológico desde el principio: para la mayoría de las tareas de empresa es Flutter o React Native multiplataforma, un solo código para iOS y Android, más barato y rápido de mantener. Si la app se lanza como MVP, el desarrollo gira en torno a un producto mínimo viable: primero el núcleo, después los extras.
En esta fase el equipo también integra cosas que no ves en pantalla pero que son críticas para el negocio: analítica de eventos, notificaciones push, gestión de errores y registros. Añadirlas después cuesta más que incluirlas desde el principio. Pregunta al equipo cómo está montado el backend y dónde se guardan los datos de los usuarios: el RGPD, por ejemplo, regula cómo se almacenan y se tratan los datos de tus usuarios en la UE.
Fase 5. Pruebas y QA
Qué pasa. Los testers prueban la app en distintos modelos de móvil y versiones del sistema operativo: buscan bugs y prueban escenarios, carga, comportamiento con mala conexión y acciones poco habituales de los usuarios. Los defectos van a un gestor de incidencias, los desarrolladores los corrigen y los testers vuelven a comprobar.
Cuánto dura. Va en paralelo al desarrollo, más un ciclo final aparte de 1–2 semanas antes del lanzamiento.
Qué recibes. Una versión estable, sin bugs críticos ni graves, lista para el lanzamiento, y un informe de pruebas. Antes del lanzamiento, la app suele pasar por una beta cerrada: la versión se comparte con un grupo pequeño de usuarios reales mediante TestFlight de Apple o un canal de pruebas cerrado en Google Play. Así se detectan problemas que en la oficina no se ven: el comportamiento en móviles de gama baja, en redes reales y con personas que tienen hábitos distintos.
En qué fijarte. El QA no es una fase «extra» que dé gusto recortar. Un bug detectado antes del lanzamiento cuesta horas; el mismo bug encontrado por un usuario en la tienda se convierte en una reseña de una estrella y en usuarios perdidos. Pregunta desde el principio en qué dispositivos se va a probar la app.
Fase 6. Publicación en las tiendas de apps
Qué pasa. La app terminada se sube al App Store y a Google Play, se prepara la ficha de la tienda (icono, capturas, una descripción con palabras clave) y la app pasa la revisión.
Cuánto dura. Google Play: de unas horas a un par de días. App Store: de 1 a 7 días, y la revisión de Apple es más estricta.
Qué recibes. Una app que la gente puede descargar de las tiendas desde tu cuenta de desarrollador.
En qué fijarte. Apple rechaza versiones por motivos que no son evidentes: falta de política de privacidad, una cuenta de prueba que no funciona, pantallas vacías, funciones que simplemente duplican un navegador. Cuenta con 1–2 rondas de correcciones tras los comentarios de la revisión: es lo normal. Registra las cuentas de desarrollador (Apple: 99 € al año; Google: un pago único de unos 23 €) a nombre de tu empresa, no del proveedor, para que la app siga siendo tuya.
Fase 7. Mantenimiento y evolución
Qué pasa. Tras el lanzamiento, la app sigue viva: salen nuevas versiones de iOS y Android que pueden romper la compatibilidad, llegan reseñas e ideas de mejora, crece la carga. El equipo actualiza la app, corrige los bugs nuevos y añade funciones según la analítica.
Cuánto dura. Es continuo, mientras la app esté publicada.
Qué recibes. Una app al día, que sigue el ritmo del sistema operativo y de la competencia, y actualizaciones periódicas.
En qué fijarte. Acuerda el formato de mantenimiento antes del lanzamiento, no después. Suele suponer un 10–20% del presupuesto del proyecto al año. Asegúrate de que la app tiene analítica de eventos: sin ella no verás en qué pantalla abandonan los usuarios y mejorarás la app a ciegas. Acuérdate también de las actualizaciones obligatorias: Apple y Google cambian sus requisitos y suben las versiones mínimas del SDK de vez en cuando, y una app que nadie actualiza acabará, en algún momento, fuera de la tienda.
Una buena práctica es recoger las opiniones de forma sistemática: seguir las valoraciones y reseñas en las tiendas, responderlas, apuntar las ideas de mejora en el backlog y priorizarlas según su impacto en tu métrica clave. Así la app crece con datos, no según quién haya pedido algo más alto.
Cuánto dura el ciclo completo
- MVP: el análisis y el diseño llevan alrededor de una semana, y el desarrollo y las pruebas, 2–3 semanas. En total, un lanzamiento en 3–4 semanas.
- App de tamaño medio: 1,5–3 meses desde la primera reunión hasta el lanzamiento.
- Producto complejo con integraciones: 4 meses o más.
Los plazos dependen mucho de lo rápido que se aprueben las cosas por tu parte. Si una sola persona responsable da el visto bueno a maquetas y estimaciones, el proyecto cumple el calendario; si cada decisión espera a una reunión, el desarrollo se queda parado entre fases. Reserva tiempo también para tu parte del trabajo: aceptación, comentarios, entrega de contenidos y accesos. Forma parte del calendario, no es ruido de fondo.
Estas fases no son estrictamente lineales: el diseño, el desarrollo y las pruebas a menudo se solapan, y los sprints permiten ajustar el producto sobre la marcha. Pero el orden y el propósito de cada fase se mantienen, y son lo que usas para tener el proyecto bajo control.
Quién trabaja en la app
Para entender qué pagas, conviene saber quién forma el equipo. Un proyecto típico cuenta con un project manager, que lleva el calendario y está en contacto contigo; un analista, que recoge los requisitos y redacta la especificación; un diseñador UX/UI, que diseña las pantallas; un desarrollador móvil, que construye la app; un desarrollador backend, que se ocupa del servidor, la base de datos y las integraciones; y un ingeniero de QA, que caza bugs. En proyectos pequeños, una misma persona combina roles; en los grandes, son personas distintas.
Como cliente, no necesitas hablar con cada uno de ellos: para eso está el project manager, tu único interlocutor. Pero importa que el equipo tenga a alguien que diseñe la lógica y a alguien que pruebe. Si en el presupuesto no hay analista ni ingeniero de QA, lo más probable es que esas fases se hagan a medias, y lo pagarás con retrabajo y bugs en producción.
En resumen
El desarrollo de una app es predecible cuando se divide en fases con un entregable claro en cada una. El análisis y la especificación marcan los límites, el diseño y el prototipo atrapan los errores antes de escribir código, los sprints muestran el avance cada dos semanas, el QA protege tu reputación y el mantenimiento mantiene vivo el producto. Tu trabajo como cliente es aceptar cada fase por su resultado, no esperar al «final».
¿Quieres un plan para tu proyecto desglosado por fases, plazos y presupuesto? Cuéntanos tu idea y te propondremos una hoja de ruta de desarrollo de apps móviles con una estimación transparente.
