Proceso de desarrollo de una app: guía para el founder que paga la cuenta
El proceso de desarrollo de una app se vende como una cinta transportadora de seis etapas. Esto es lo que de verdad ocurre en cada una, cuál es tu única tarea y dónde el founder pierde en silencio el control del producto que está pagando por construir.
Una founder con la que trabajamos lo había aprobado todo. Firmó los wireframes, asintió en cada demo de sprint y le reenvió la fecha de lanzamiento a su inversor principal. Tres semanas antes del go-live, el desarrollador comentó, de pasada, que la app no podía enviar el correo de restablecer contraseña. Nunca había estado en el alcance. Nadie le había mentido. Simplemente aprobó seis meses de trabajo sin saber ni una vez qué se suponía que debía estar revisando en cada paso.
El proceso de desarrollo de una app es la secuencia que recorre una idea de software hasta convertirse en un producto que funciona: discovery, diseño, construcción, pruebas, lanzamiento y mantenimiento. Toda agencia y toda software house lo describe como un conjunto ordenado de etapas, casi siempre numeradas, casi siempre con una flecha apuntando a la derecha. Ese dibujo es cierto e inútil. Cierto porque esas fases de verdad ocurren en ese orden. Inútil porque está dibujado desde la silla de quien construye, y tú no estás en esa silla. Eres quien paga la cuenta, y tu tarea en cada fase es distinta de la de ellos.
Esta es una guía sobre esas mismas seis fases desde el lugar en el que de verdad estás sentado. Para cada una: qué ocurre, la única cosa que te toca acertar y la señal concreta de que la fase va mal mientras todos siguen sonriendo.
La única regla que rige todo el proceso de desarrollo de una app
Antes de las fases, la regla que da sentido a todas ellas:
Tu capacidad de influir sobre un build es máxima antes de que se escriba una sola línea de código, y cae cada semana después. Gasta tu atención donde más vale: en las dos fases previas a la construcción, no en los standups durante ella.
La mayoría de los founders primerizos hace lo contrario. Se mantiene al margen durante el discovery y el diseño, cuando una frase suya podría redirigir todo el proyecto, y luego se llena de ansiedad y se involucra durante la construcción, cuando las decisiones caras ya están en concreto. Para cuando estás mirando los standups diarios, estás administrando el clima. La influencia se fue sin ti.
Fase 1: Discovery, decidir qué no construir
El discovery es donde el equipo convierte tu idea en una lista concreta de lo que la versión uno hará y no hará. Los buenos equipos hacen entrevistas, bocetan flujos y fijan el puñado de cosas que el producto debe hacer para que valga la pena lanzarlo. Los equipos flojos se saltan esto y empiezan a dibujar pantallas, lo que parece progreso y en realidad es adivinar con una herramienta más bonita.
Tu única tarea aquí es restar. El equipo puede agregar features todo el día; solo tú puedes decidir qué no necesita el negocio en la primera versión. Cada feature que cortas en el discovery es dinero que no gastas y un bug que nunca tendrás que arreglar. Esta es la fase en la que el trabajo de discovery de producto se paga muchas veces, porque es el lugar más barato de todo el proceso para cambiar de opinión.
La señal de alerta: el equipo quiere empezar a construir en la primera semana y trata el discovery como un trámite. Una software house ansiosa por saltarse el discovery es una software house a la que le pagan por construir, no por pensar, y la diferencia aparecerá en tu factura dentro de tres meses en forma de retrabajo.
Fase 2: Diseño, el último lugar barato para equivocarse
El diseño convierte las decisiones del discovery en algo que puedes ver y clicar: primero los wireframes (el esqueleto), luego mockups de mayor fidelidad y normalmente un prototipo interactivo. Esta es la última fase en la que cambiar de opinión cuesta una tarde en lugar de una semana. Mover un botón en un archivo de diseño es gratis. Moverlo después de conectarlo a datos reales y probarlo, no.
Tu tarea es clicar el prototipo como un cliente desconfiado, no admirarlo como un padre orgulloso. Intenta hacer las tres cosas que tus usuarios reales harán con más frecuencia. Si alguna de ellas requiere más toques de los que debería, dilo ahora. Entender la diferencia entre un wireframe y un mockup importa aquí, porque los founders suelen aprobar un esqueleto gris creyendo que aprobaron el aspecto final, y luego se sienten engañados cuando llega lo real.
La señal de alerta: te muestran imágenes estáticas y te piden que imagines el flujo. Si no puedes recorrer de verdad el recorrido principal con el dedo antes de que empiece la construcción, estás aprobando una historia sobre la app, no la app.
Fase 3: Construcción, donde tu influencia ya está gastada
Ahora los ingenieros escriben el código. Esta es la fase más larga y más cara y, contra la intuición, aquella en la que menos tienes que aportar. Las decisiones que importaban se tomaron en las dos fases que quizá atravesaste con prisa. Lo que aún puedes hacer aquí es proteger el build de ti mismo.
Cada vez que introduces una idea nueva a mitad de la construcción, no estás agregando una feature, estás reabriendo el plan. El equipo tiene que resecuenciar el trabajo, y el costo rara vez es solo lo nuevo; es todo lo que lo nuevo toca. Ese es el mecanismo detrás de la mayoría de los plazos reventados. Si quieres entender por qué se movió el número, lee tu estimación de desarrollo de software como un rango que asume que dejas de cambiar de opinión, porque ese supuesto está haciendo un trabajo silencioso y enorme.
Tu única tarea durante la construcción es mantener una versión que funciona frente a ti. Pide un enlace que puedas abrir tú mismo, no una grabación de pantalla que alguien editó. El software que solo existe en una demo es software que no puedes inspeccionar. La señal de alerta es una fase de construcción en la que cada actualización es una diapositiva y nunca un enlace.
Fase 4: Pruebas, la fase que se recorta primero
Las pruebas son donde el equipo intenta romper la app antes de que lo hagan tus clientes: si funciona en un Android barato, si sobrevive a una red mala, qué pasa cuando alguien escribe un emoji en el campo del nombre. Es la fase con más probabilidades de ser comprimida en silencio cuando la construcción se atrasa, porque es lo último que queda de pie entre una fecha que se escapa y un lanzamiento.
No puedes leer el código de prueba, pero puedes pedir el resultado: un informe corto de qué se probó, qué se rompió y qué se arregló. No estás auditando la ingeniería. Estás comprobando que las pruebas ocurrieron como una actividad con una salida, y no como una palabra que alguien dijo en una reunión. El correo de restablecer contraseña que nadie puso en el alcance es exactamente el tipo de cosa que una ronda de pruebas de verdad detecta y una comprimida no.
La señal de alerta: “fuimos probando sobre la marcha” ofrecido como sustituto de una fase de pruebas. Probar sobre la marcha es buena práctica y una mala excusa. Si no hay un artefacto que muestre qué se revisó, asume que la cobertura es la que resultó cómoda.
Fase 5: Lanzamiento, un evento de ingeniería antes que de marketing
El lanzamiento no es la fiesta. Es el trabajo aburrido y de alto riesgo de poner la app frente a usuarios reales sobre infraestructura real: revisión de la app store, datos de producción, monitoreo y un plan para la primera vez que algo se rompa a las dos de la mañana. El lanzamiento de marketing puede esperar una semana. El lanzamiento de ingeniería tiene cien puertas pequeñas que hay que cerrar todas, y la mayoría son invisibles para ti.
Tu tarea es saber quién tiene el pager en la mano. Haz una pregunta: cuando algo se rompa en las primeras 48 horas, quién se entera y en cuánto tiempo puede arreglarlo. Si la respuesta es vaga, no tienes un plan de lanzamiento, tienes una esperanza. El lanzamiento también tiene porteros que no controlas: las directrices de revisión de la App Store de Apple pueden rechazar un build por motivos que nada tienen que ver con si funciona, y un rechazo a pocos días de tu fecha es un problema de lanzamiento que quieres oír en la fase uno, no en la fase cinco.
La señal de alerta: el plan de go-live es una fecha y nada más. Una fecha no es un plan. Un plan dice quién hace qué cuando ocurre lo que no esperabas.
Fase 6: Mantenimiento, la fase que todos olvidan cotizar
El software no es un edificio que se queda de pie una vez que cortas la cinta. Los teléfonos se actualizan, las bibliotecas se rompen, los usuarios encuentran bordes que nunca imaginaste, y la app necesita atención constante y sin glamour para seguir funcionando. El mantenimiento no es una fase después del proceso; es el proceso que no termina. Los founders que tratan el lanzamiento como línea de meta lo descubren la primera vez que Apple cambia algo y su app deja de abrir.
Tu tarea es rechazar la idea de que el mantenimiento es opcional. Decide, antes del lanzamiento, quién mantiene las luces encendidas y cuánto cuesta al mes. La versión más barata de esta conversación ocurre ahora. La versión más cara ocurre después de que tu único desarrollador se fue y nadie de los que quedan puede tocar una línea con seguridad.
La señal de alerta: una propuesta que termina en el lanzamiento, sin una línea sobre lo que pasa después. Un build sin plan de mantenimiento es un coche vendido sin ninguna forma de comprar combustible.
La prueba del handoff: cómo saber que una fase de verdad terminó
Esta es la única herramienta que amarra las seis fases. En cada frontera entre fases hay un artefacto que deberías poder sostener en la mano:
- Después del discovery: un alcance de una página que puedas leer en cinco minutos y que liste lo que quedó fuera, no solo lo que quedó dentro.
- Después del diseño: un prototipo clicable del recorrido principal, no una carpeta de imágenes.
- Después de la construcción: un enlace a una versión que funciona y que puedes abrir tú mismo.
- Después de las pruebas: un informe corto de qué se revisó y qué se rompió.
- Después del lanzamiento: un runbook que nombre quién responde cuando algo falla.
La prueba es simple. Si una fase termina y no puedes sostener su artefacto, la fase no terminó de verdad. Solo empujó su riesgo aguas abajo, a la fase siguiente y, al final, a ti. Todo desastre en un build es alguna versión de una fase declarada terminada sin producir la cosa que prueba que terminó. La prueba del handoff es como un founder no técnico audita un proceso cuyo código no puede leer: no revisas el trabajo, revisas que cada fase dejó evidencia detrás.
Vas a notar que esto también te dice en qué software house confiar. Un equipo que piensa en artefactos te los entrega sin que los pidas. Un equipo que piensa en facturas te entrega un estado y espera que te sientas tranquilo. La forma en que eliges una empresa de desarrollo debería apoyarse con fuerza en esto: pregunta qué vas a poder sostener al final de cada fase y observa si la respuesta es concreta.
Preguntas frecuentes
¿Cuáles son las etapas del proceso de desarrollo de una app?
Seis: discovery (decidir qué construir), diseño (hacerlo visible y clicable), construcción (escribir el código), pruebas (romperlo antes que los usuarios), lanzamiento (subirlo con seguridad) y mantenimiento (mantenerlo funcionando). Algunas guías dividen esto en siete o doce pasos, pero los números extra suelen ser subtareas de estas seis. El número importa menos que saber cuál es tu tarea en cada una.
¿Cuánto dura el proceso de desarrollo de una app?
Una primera versión de verdad suele tardar de tres a seis meses, con discovery y diseño tomando unas semanas y la construcción llevándose el grueso. La respuesta honesta depende de cuánto cortes en el discovery y de cuántas veces cambies de opinión durante la construcción. Las dos palancas que controlas están al frente del proceso, no en el medio.
¿Cuál es la fase más importante para un founder no técnico?
Las dos previas a la construcción: discovery y diseño. Ahí es donde tu influencia es mayor y un cambio cuesta menos. Los founders que invierten su atención ahí y luego dan un paso atrás durante la construcción obtienen apps mejores por menos dinero que los founders que hacen lo contrario.
¿Puedo saltarme el discovery para ir más rápido?
Puedes, y es la forma más común de gastar más para obtener menos. Saltarte el discovery no elimina las decisiones sobre qué construir; solo las empuja a la fase de construcción, donde cambiarlas cuesta diez veces más. Las salidas rápidas aquí suelen comprar llegadas lentas.
¿Cómo mantengo el control de un build que no puedo evaluar técnicamente?
Usa la prueba del handoff. Al final de cada fase, pide el artefacto que prueba que ocurrió: una página de alcance, un prototipo clicable, un enlace que funciona, un informe de pruebas, un runbook. No necesitas leer código para notar cuándo una fase terminó sin dejar evidencia detrás.