El proceso de desarrollo de una app, etapa por etapa

Si nunca has desarrollado software, el proceso puede parecer una caja negra: sale el dinero y, meses después, aparece una app (o no). No debería funcionar así. Un buen proceso se ve en cada paso.

Así llevo los proyectos en Loha.dev, y así trabajan, más o menos, la mayoría de los estudios serios. Para cada etapa: qué pasa, qué recibes, qué necesitamos de ti y cuánto suele tardar (estimaciones, no promesas).

Las siete etapas del desarrollo de aplicaciones de un vistazo

Si lo sumas, una primera versión enfocada suele quedar entre 3 y 6 meses. Un MVP sencillo puede ir más rápido; las apps con integraciones complejas, pagos o requisitos regulatorios exigentes tardan más. Para ver con detalle qué mueve esas cifras, lee cuánto tiempo se tarda en desarrollar una app.

Etapa 1: Descubrimiento y estrategia

En el descubrimiento decidimos qué construir y qué dejar para después. La mayoría de las apps que fracasan no fallan por el código. Fallan porque la versión uno quiso hacerlo todo.

Qué pasa

• Entrevistas sobre tu negocio, tus usuarios y cómo vas a ganar dinero con la app.
• Una lista con todas las ideas de funciones, ordenadas después por valor y esfuerzo.
• Recortar esa lista hasta una primera versión capaz de validar la idea.
• Detectar riesgos temprano: APIs de terceros, pagos, privacidad de datos, funciones de IA, políticas de las tiendas.

Entregables

Un brief breve del producto, una lista de funciones priorizada con la línea del MVP bien marcada, un boceto de la arquitectura y un rango de presupuesto y plazo con el que puedas planificar.

Tu papel

Es la etapa en la que más participas. Cuenta con dos a cuatro sesiones de trabajo. Trae ejemplos de apps que te gusten, datos o comentarios de clientes que ya tengas y a la persona que toma las decisiones finales.

Duración típica (estimación): 1–3 semanas.

Etapa 2: Diseño UX/UI

El diseño trata primero de cómo funciona la app y después de cómo se ve. La UX define las pantallas y los flujos: cómo alguien se registra y completa la tarea principal. La UI es la capa visual: tipografía, color, componentes.

Qué pasa

• Flujos de usuario para los recorridos clave, normalmente de 3 a 6 en una primera versión.
• Wireframes de baja fidelidad para acordar la estructura antes de que alguien discuta sobre colores.
• Pantallas de alta fidelidad y un pequeño sistema de diseño (botones, campos, tarjetas, estados).
• Un prototipo navegable que puedes recorrer en tu teléfono y mostrar a usuarios reales.

Entregables

Wireframes, diseños finales de cada pantalla del MVP (incluidos los estados vacíos, de carga y de error, que casi todos olvidan), un prototipo navegable y una librería de componentes reutilizables.

Tu papel

Revisa los diseños a tiempo y da comentarios concretos ("el pago tiene demasiados pasos" sirve mucho más que "hazlo más llamativo"). Si puedes, pon el prototipo en manos de cinco usuarios potenciales. Es la investigación de usuarios más barata que vas a hacer.

Duración típica (estimación): 2–4 semanas.

Etapa 3: Arquitectura y stack tecnológico

Mientras se cierra el diseño, se ponen los cimientos técnicos. El cliente casi no lo ve, pero esto decide cuánto costará cambiar la app más adelante.

Qué pasa

• Elegir el stack: nativo con Swift/Kotlin o multiplataforma. Yo suelo trabajar con React Native y Expo, así un solo código en TypeScript llega a iOS, Android y muchas veces también a la web.
• Diseñar el modelo de datos y el backend. Para apps que necesitan actualizaciones en vivo (chat, colaboración, paneles) me apoyo en backends en tiempo real como Convex.
• Planificar las integraciones: autenticación, pagos, notificaciones push, analíticas, proveedores de IA/LLM.
• Configurar el repositorio, los entornos (desarrollo, staging, producción), la CI y los pipelines de compilación automáticos.

Entregables

Un plan técnico breve, un esqueleto del proyecto que compila y se despliega, y las cuentas creadas a tu nombre (Apple Developer, Google Play Console, hosting en la nube). Esas cuentas deben ser tuyas desde el primer día, no de tu desarrollador.

Tu papel

Crear o aprobar las cuentas de desarrollador y de hosting, y tomar las pocas decisiones de negocio que afectan a la arquitectura: qué proveedor de pagos usar, si necesitas modo sin conexión, en qué regiones están tus usuarios.

Duración típica (estimación): 1–2 semanas, normalmente en paralelo con el diseño.

Etapa 4: Sprints de desarrollo

Es la etapa más larga y la que la gente imagina cuando piensa en "hacer una app". El trabajo se divide en sprints, ciclos cortos de una o dos semanas, y cada uno termina con algo que puedes usar de verdad.

Qué pasa

• Cada sprint empieza con una llamada corta de planificación: qué funciones de la lista priorizada entran ahora.
• Las funciones se construyen completas (pantalla, lógica, backend, tests), en lugar de hacer primero todas las pantallas y después todo el backend.
• Cada sprint termina con una demo y una versión de prueba nueva en tu teléfono.
• El alcance se ajusta según lo que aprendes usando la app real.

Entregables

Funciones operativas y probadas cada una o dos semanas, una versión de prueba que puedes instalar y un resumen escrito breve: qué se entregó, qué sigue y qué está bloqueado.

Tu papel

Asistir a la demo semanal (30 minutos suelen bastar), usar la versión de prueba y responder preguntas en uno o dos días. Las decisiones lentas son la causa más común de retrasos, por encima de cualquier problema técnico.

Duración típica (estimación): 6–16 semanas para una primera versión, según el alcance.

Cómo funcionan las demos semanales y las versiones de prueba

Con Expo puedo enviar una nueva versión de la app a tu teléfono sin pasar cada vez por la App Store. Instalas una versión de prueba una sola vez y las actualizaciones llegan a medida que las publicamos. En iOS, las compilaciones más grandes pasan por TestFlight; en Android, por un canal de pruebas internas de Play o un enlace de instalación directa. Las versiones web tienen una URL de vista previa para cada cambio.

La demo semanal es una pantalla compartida más la app en tus propias manos. Ves avances reales, no diapositivas, y detectas malentendidos en la semana 3 en vez de en la semana 12.

Ágil o alcance cerrado: ¿qué te conviene?

Hay dos formas generales de contratar el desarrollo de una app, y cada una cambia cómo se vive el proceso.

Mi opinión sincera: para un producto nuevo, el alcance cerrado puro suele salir mal. Las agencias inflan la cotización para cubrir lo desconocido, y cada buena idea que tienes a mitad del proyecto se convierte en una negociación. El modelo ágil sin límites también puede descontrolarse.

Lo que mejor funciona, en mi experiencia, es un modelo híbrido: una etapa de descubrimiento y diseño a precio fijo y luego desarrollo por sprints con un tope de presupuesto y una lista priorizada. Siempre sabes el máximo que vas a gastar y conservas la libertad de cambiar una función cuando el prototipo te enseña algo. Si estás comparando estudios, pregunta exactamente cómo manejan los cambios; es una de las preguntas clave para elegir una empresa de desarrollo de apps.

Etapa 5: QA y pruebas

Las pruebas acompañan cada sprint y, antes del lanzamiento, tienen un periodo dedicado de estabilización.

Qué pasa

• Pruebas en dispositivos reales: iPhones antiguos y nuevos, una variedad de teléfonos Android (los tamaños de pantalla y los fabricantes cambian mucho), tablets si las soportas, además de redes lentas y comportamiento sin conexión.
• Tests automatizados: tests unitarios para la lógica de negocio, tests de integración para el backend y tests de extremo a extremo para flujos críticos como el registro y el pago, ejecutados en la CI con cada cambio.
• Pruebas beta: un grupo de usuarios reales instala la app mediante TestFlight de Apple y los canales de pruebas internas o cerradas de Google Play. TestFlight admite hasta 100 testers internos y hasta 10.000 externos (las versiones externas pasan por una revisión ligera de Apple).
• Monitoreo de fallos y errores configurado antes de la beta, para que los problemas lleguen con trazas de error y no con reportes vagos.

Entregables

Un plan de pruebas, una suite de tests automatizados en la CI, versiones beta en ambas plataformas y una lista de errores clasificada en la que todo lo que bloquea el lanzamiento está resuelto.

Tu papel

Reclutar testers para la beta (clientes, personal, amigos que encajen con el usuario objetivo), usar la app a diario durante la beta y decidir qué errores no críticos pueden esperar a la versión 1.1.

Duración típica (estimación): continua durante el desarrollo, más 1–3 semanas de beta y estabilización.

Etapa 6: Lanzamiento

Lanzar significa superar la revisión de las tiendas y activar producción.

Qué pasa

• Preparar las fichas de las tiendas: nombre, subtítulo, descripción, palabras clave, capturas, video de vista previa, datos de privacidad y clasificación por edad.
• Enviar la app a la App Store de Apple y a Google Play. La revisión de Apple suele resolverse en uno o dos días, aunque puede tardar más, y los rechazos ocurren, casi siempre por la información de privacidad, los requisitos de inicio de sesión o metadatos incompletos.
• Desplegar el backend de producción, activar el monitoreo y las analíticas y planificar un lanzamiento escalonado cuando tenga sentido.

Entregables

Tu app publicada en las tiendas (y en la web si aplica), un entorno de producción con monitoreo, y la documentación y las credenciales entregadas a ti.

Tu papel

Aportar los textos y materiales de marketing, aprobar las fichas de las tiendas, proporcionar los documentos legales (política de privacidad, términos, URL de soporte) y preparar tu marketing de lanzamiento. El paso a paso completo está en nuestra guía sobre cómo publicar una app en la App Store y Google Play.

Duración típica (estimación): 1–2 semanas, con margen para la revisión.

Etapa 7: Mantenimiento e iteración tras el lanzamiento

El lanzamiento es el comienzo del producto, no el final del proyecto. Los usuarios reales siempre hacen algo que nadie había previsto.

Qué pasa

• Corregir errores que solo aparecen a escala real o en dispositivos poco comunes.
• Mantenerse al día con las versiones anuales de iOS y Android, las actualizaciones de SDK y los cambios en las políticas de las tiendas. Una app que nadie mantiene termina fallando o siendo retirada.
• Revisar analíticas y comentarios de usuarios, y luego hacer nuevos ciclos de diseño y sprints para las versiones 1.1, 1.2 y siguientes.
• Vigilar los costos de hosting y de APIs, sobre todo en funciones de IA, donde el precio por uso puede crecer rápido.

Tu papel

Hablar con tus usuarios, decidir qué es lo más importante después y presupuestarlo. Una estimación habitual para planificar es del 15–20% del costo inicial de desarrollo al año solo en mantenimiento, sin contar funciones nuevas.

Duración típica: continua, normalmente con una cuota mensual o en ciclos de funciones planificados.

Cómo es este proceso en Loha.dev

Llevo los proyectos con las etapas anteriores, comprimidas cuando tiene sentido. Para un fundador en etapa temprana, nuestro trabajo de desarrollo de MVP suele unir descubrimiento y diseño en unas pocas semanas intensas y pone una versión funcional en tu teléfono rápido. Para empresas que quieren reemplazar hojas de cálculo o herramientas antiguas, el desarrollo de aplicaciones a medida dedica más tiempo al descubrimiento para mapear los flujos de trabajo existentes.

En ambos casos el stack es el mismo: React Native y Expo para el desarrollo de apps móviles en iOS y Android, React para la web, TypeScript, Convex y Cloudflare. Es la base de nuestra propia app Star, una app de setlists y presentaciones para tablets y web.

Si quieres ver cómo se aplicarían estas etapas a tu idea, obtén un plan gratuito para tu app. Recibirás un alcance sugerido, un desglose por etapas y un rango estimado, sin compromiso.