Cómo lanzar una app: la guía del founder no técnico

Una guía, desde la silla del founder, para poner en producción un software a medida: cómo saber cuándo una app está realmente lista, las cuatro decisiones de lanzamiento que solo tú puedes tomar y qué vigilar en las primeras 48 horas.

Una founder con la que trabajamos recibió el mensaje que todo founder no técnico espera: “Está listo. Todo funciona.” Esa misma tarde anunció la app en LinkedIn, pegó el enlace de descarga y se fue a cenar. Para cuando llegó el postre, la pantalla de registro ya daba error a la mitad de las personas que la tocaban, y los correos de bienvenida habían dejado de salir en silencio. El código estaba terminado. La app no estaba lanzada.

Esa distancia es el juego entero. Cómo lanzar una app, para un founder no técnico, es el trabajo de llevar el producto de “el equipo de desarrollo dice que terminó” hasta “personas reales lo están usando en producción y nada se cae”. Lanzar es un evento de ingeniería, no un anuncio de marketing. El anuncio es la parte fácil. Casi todos los consejos que encuentras en internet saltan directo a él.

Terminado no es lanzado

Busca “cómo lanzar una app” y encontrarás dos tipos de artículo. Uno es una checklist de marketing: optimiza la ficha de la tienda, alinea prensa, configura tus etiquetas de atribución. El otro es una plataforma no-code diciéndote que pulses su botón de publicar. Los dos tratan el lanzamiento como el último 5% del marketing. Ninguno habla de la parte que de verdad se rompe.

Vale la pena quedarse con este replanteo: lanzar una app es un evento de ingeniería antes de ser un evento de marketing. El riesgo que tumba a los founders el primer día casi nunca es “poca prensa”. Es la base de datos que nunca se probó con tráfico real, el webhook de pago que falla en silencio, el flujo de recuperar contraseña que nadie pulsó porque todos los que probaron ya tenían cuenta. Terminado quiere decir que las funcionalidades existen. Lanzado quiere decir que sobreviven al contacto con quien no las construyó.

Para un founder no técnico esto es incómodo, porque el evento de ingeniería es justo la parte para la que te sientes menos preparado. Así que lo delegas todo y cruzas los dedos. Ese es el error. No puedes escribir el script de deploy, pero sí puedes ser dueño de las decisiones a su alrededor, y son esas decisiones las que determinan si tu lanzamiento es una celebración o un incendio.

Antes de lanzar: el test de preparación

Tener las funcionalidades completas no es lo mismo que estar listo. Un founder necesita una forma de ver la diferencia sin leer código. El test que damos a los founders con los que trabajamos es simple: ¿podría un desconocido usar el flujo principal, en su propio teléfono, con sus propios datos, mientras tú observas y no dices nada?

Esa última parte importa. Si tienes que inclinarte y explicar, no está listo. Si la demo solo funciona en el portátil del desarrollador con una cuenta de prueba preparada, no está listo. La confianza del equipo de desarrollo no es prueba; su confianza está calibrada para un entorno que ellos controlan.

Haz un ensayo general antes de lanzar. Elige a tres o cuatro personas parecidas a tus usuarios reales que nunca hayan visto la app. Dales un teléfono, una tarea real y silencio. Observa dónde se traban. Esto es distinto del visto bueno que diste en las pruebas de aceptación del usuario, donde comprobabas el build contra la especificación. El ensayo general comprueba el build contra un humano que ni sabe que la especificación existe.

Algunas cosas deben ser ciertas antes de salir a producción, y puedes confirmar cada una sin ser técnico:

• Alguien puede registrarse, hacer la única cosa para la que existe la app y volver mañana para encontrar sus datos todavía ahí.
• Los pagos, si cobras, se probaron con una tarjeta real, no una de prueba, y el dinero de verdad se movió.
• Los criterios de aceptación que acordaste para las funcionalidades del lanzamiento pasan todos, comprobados por ti, no descritos a ti.
• Sabes qué pasa cuando algo falla: ¿el usuario ve un mensaje claro o una pantalla en blanco?
• Si tu app va a la tienda de Apple o de Google, ya pasó la revisión. Lee las directrices de revisión de la App Store de Apple antes de enviarla, porque un rechazo puede costarte una semana que no tenías prevista.

Si no consigues un pase limpio en esos puntos, todavía no tienes fecha de lanzamiento. Tienes un objetivo.

Las cuatro decisiones de lanzamiento que solo tú puedes tomar

No vas a hacer el deploy de la app. Pero cuatro decisiones son tuyas, y ningún desarrollador puede tomarlas por ti, porque cada una es sobre el negocio, no sobre el código.

La decisión de ir o no ir. En algún momento alguien tiene que decir “vamos” o “esperamos”. Si se la dejas al equipo de desarrollo, la decisión se toma por defecto en el instante en que el código entra, que es exactamente como nuestra founder terminó anunciando una app rota durante la cena. Agenda una conversación de ir/no ir, con el test de preparación como temario. Tú tomas la decisión, en voz alta, un día concreto.

La decisión de revertir, el rollback. Antes de lanzar, haz una pregunta: si esto sale mal en la primera hora, ¿cómo lo apagamos? A veces la respuesta es “volvemos a la versión anterior en dos minutos”. A veces es “no se puede, la nueva estructura de la base de datos es de un solo sentido”. Necesitas saber en qué mundo estás antes del lanzamiento, no durante el incendio. Un socio que no responde esto con claridad te está diciendo algo.

Quién está de guardia, el on-call. Los lanzamientos de verdad se rompen a horas inconvenientes. Decide, por escrito, quién vigila el sistema en las primeras 48 horas y cómo lo localizas a las 11 de la noche. “Todos andan por ahí” no es un plan. Una persona con nombre, un número de teléfono, una ventana acordada. Esta es la parte de pasar la noche depurando, y es justo la parte que los arreglos baratos dejan fuera en silencio.

El plan de los primeros usuarios. ¿Quién usa la app primero, y cuántos? La respuesta casi nunca debería ser “todos, a la vez”. Lo que nos lleva a la parte que la mayoría de los founders se salta.

Soft launch antes de hard launch

Un hard launch es el gran anuncio: el post en LinkedIn, la prensa, el correo a toda tu lista. Un soft launch es dejar entrar primero a un goteo controlado de usuarios reales, observar, corregir y solo entonces abrir las puertas.

La razón para hacer un soft launch no es cautela por cautela. Es que tus primeros usuarios reales encontrarán problemas que tus usuarios de prueba nunca pudieron, y quieres encontrarlos a un volumen que de verdad puedas arreglar. Veinte usuarios reales sacando cinco bugs es un martes cualquiera. Dos mil usuarios sacando los mismos cinco bugs es un problema de reputación y una cola de soporte que no puedes vaciar.

Una secuencia que funciona: abre a un puñado de usuarios amistosos que perdonarán las asperezas y te dirán la verdad. Luego a un grupo un poco más amplio que no te conoce. Observa cada grupo un par de días. Si el flujo principal aguanta y los números tienen sentido, amplía otra vez. Tu hard launch llega cuando ya viste a desconocidos de verdad usar la cosa y no se cayó. A esas alturas el anuncio es una formalidad, que es como debe sentirse. El lanzamiento ya pasó, en silencio, y funcionó.

Esta también es la respuesta honesta para los founders que creen que lanzar es un único día dramático. Los buenos lanzamientos en los que participamos eran aburridos por fuera. El drama, cuando lo había, ocurrió dos semanas antes con doce usuarios y se resolvió antes de que nadie estuviera mirando.

Las primeras 48 horas: qué vigilar

Con usuarios reales dentro, tu trabajo cambia de decidir a observar. No necesitas un panel lleno de métricas de vanidad. Necesitas saber, casi en tiempo real, si la cosa funciona. Tres preguntas cubren casi todo.

¿La gente está entrando? Los registros que empiezan y no terminan son la señal temprana más ruidosa de que algo en el embudo se rompió. ¿Están haciendo esa única cosa? Si los usuarios llegan y nunca alcanzan la acción principal, o está escondida o está rota. ¿Y hay algo ardiendo entre bastidores? Errores, pagos fallidos, correos que no salieron. Tu equipo de desarrollo puede poner una alerta simple para que un humano se entere de los fallos antes de que un usuario se queje en Twitter.

Acuerda antes del lanzamiento qué se vigila y quién lo vigila. El founder no necesita leer los logs. El founder necesita saber que alguien los lee, y que ese alguien va a llamar.

Quién aprieta el botón de verdad

Si no eres técnico, la pregunta honesta debajo de todo esto es: ¿quién hace el deploy de mi app, y cuánto tengo que confiar en esa persona? No vas a correr el release tú mismo. Está bien. Muchos founders serios nunca tocan el deploy. Lo que no puedes hacer es tratarlo todo como una caja negra y enterarte de quién era el responsable solo después de que se rompe.

Los socios de tecnología no deberían ser cajas negras. El estudio o desarrollador que pone tu app en producción debería poder decirte, en lenguaje sencillo, qué implica el lanzamiento, cómo sabrán que funcionó, cómo lo desharían y quién está despierto si se rompe. Si esas respuestas vuelven vagas, la vaguedad es el aviso. El equipo que recibe bien una conversación de ir/no ir y ya tiene listo un plan de reversión es el equipo que vale la pena conservar. El trabajo del día del lanzamiento es real, con las manos en la masa, y a veces ocurre a las 2 de la madrugada. El socio correcto ya lo sabe y ya lo planificó.

Lo que lanzas, al final, es la versión más pequeña del producto que pondrías con orgullo frente a un cliente que paga. Lánzalo como si importara, porque la primera impresión es la que no recuperas. Después observa, corrige lo que el mundo real encuentre y deja que el anuncio sea la vuelta de la victoria discreta que debe ser.

Preguntas frecuentes

¿Cuánto cuesta lanzar una app?
Las tarifas de las tiendas son pequeñas: Apple cobra una cuota anual de desarrollador y Google una cuota única. El costo real de lanzar no es la ficha en la tienda, es la preparación y la guardia: el ensayo general, la corrección de bugs en la ventana del soft launch y alguien vigilando el sistema los primeros días. Reserva presupuesto para el trabajo alrededor del go-live, no solo para el build. Nuestro desglose de cuánto cuesta desarrollar una app muestra a dónde va ese dinero.

¿Puedo lanzar una app gratis?
Puedes publicar en la web por casi nada, y las tarifas de las tiendas son modestas. Pero “gratis” suele significar que nadie está de guardia cuando se rompe y nadie hizo un ensayo general de verdad. Eso no es un lanzamiento, es una apuesta. El costo que importa es la atención en las primeras 48 horas, y la atención no es gratis.

¿Cuál es la diferencia entre soft launch y hard launch?
Un soft launch deja entrar primero a un grupo controlado de usuarios reales para que encuentres y corrijas problemas en silencio. Un hard launch es el anuncio público para todos. Soft launch primero, siempre. El hard launch debería sentirse anticlimático, porque el lanzamiento de verdad ya pasó y aguantó.

¿Quién hace el deploy de mi app si no soy técnico?
Tu desarrollador o estudio lo hace. No necesitas correr el release, pero sí necesitas saber quién es el responsable, cómo confirmarán que funcionó y cómo lo revertirían. Si tu socio no puede explicar el lanzamiento en lenguaje sencillo, eso es un problema que conviene resolver antes del go-live, no después.

¿Cómo sé que mi app está realmente lista para lanzar?
Haz el test de preparación: un desconocido parecido a tus usuarios reales completa el flujo principal en su propio teléfono, con sus propios datos, mientras tú observas y no dices nada. Si pasa sin tu ayuda y sus datos siguen ahí al día siguiente, estás cerca. También ayuda confirmar que el lanzamiento es el producto mínimo viable correcto y que tus criterios de aceptación y las pruebas de aceptación del usuario pasaron antes de fijar una fecha.