Checklist para lanzar tu MVP si no eres técnico

Antes de lanzar un MVP, asegúrate de que se cumplan cinco cosas: que todas las cuentas donde corre la app sean tuyas, que cada usuario vea solo sus propios datos, que los pagos y correos funcionen en modo real, que te enteres cuando algo falle y que la gente tenga cómo contactarte. Todo lo demás (los detalles, funciones extra, un diseño perfecto) puede esperar a la versión dos.

Esta lista está pensada para fundadores que no escribieron el código, incluidas las apps hechas con Lovable, Bolt, Replit o por un freelancer. Recórrela una o dos semanas antes del lanzamiento, no la noche anterior.

¿Todo aquello en lo que corre la app es tuyo?

Lanzar sobre cuentas que no controlas es uno de los riesgos más comunes en productos nuevos, y no se nota hasta que algo sale mal.

• El código está en un repositorio que pertenece a la cuenta de tu empresa, y puedes entrar.
• El dominio está a tu nombre o al de tu empresa, con renovación automática.
• Hosting, base de datos, proveedor de correo y cuenta de pagos están a tu nombre y con tu correo.
• Al menos dos personas pueden entrar a cada cuenta crítica, y la verificación en dos pasos está activada.
• Todos los que ayudaron a construir la app firmaron un acuerdo que te cede el código. Nuestra explicación sobre quién es dueño del código hecho con IA cuenta por qué importa.

¿Los datos de los usuarios están protegidos?

• Crea dos cuentas de prueba y confirma que la cuenta A no puede ver ni editar nada de la cuenta B, ni siquiera cambiando un ID en la URL.
• Si usas Supabase, Row Level Security está activado en todas las tablas con datos de usuarios, con políticas que reflejan quién debe ver qué.
• No hay claves secretas (service role de Supabase, clave secreta de Stripe, clave de OpenAI) en el código del frontend.
• Las pantallas de administración exigen un rol de admin validado en el servidor, no solo un enlace escondido.
• Los respaldos están activos y sabes cómo restaurar uno.

¿Los flujos principales funcionan en producción?

Prueba en el dominio real, no en la vista previa, desde un teléfono y desde una computadora.

1. Regístrate con un correo nuevo, confírmalo e inicia sesión.
2. Recupera la contraseña y entra con la nueva.
3. Haz de principio a fin la acción principal para la que existe tu app.
4. Cierra sesión, vuelve a entrar y revisa que los datos sigan ahí.
5. Repite en una ventana privada y en otro navegador.

Pagos

• Stripe (o tu proveedor) está en modo real, con claves reales en producción y claves de prueba solo en los entornos de prueba.
• El webhook apunta a la URL de producción y su secreto de firma es el del modo real.
• Haz una compra real con tu propia tarjeta, confirma que se da el acceso y luego reembólsala. Vale la pena leer completa la lista de Stripe para pasar a producción.

Correos

• Llegan el de registro, el de recuperación de contraseña y los recibos, y no caen en spam.
• Los correos salen desde tu propio dominio, con registros SPF, DKIM y DMARC configurados. Mira por qué los correos de tu app llegan a spam.

¿Te vas a enterar cuando algo falle?

• Tienes una herramienta de seguimiento de errores que te avisa de fallos del frontend y del backend con detalles.
• Un monitor de disponibilidad revisa el sitio y te alerta por correo o mensaje.
• Sabes dónde leer los registros del hosting y de la base de datos.
• Escribiste qué hacer si el sitio se cae: a quién llamar y cómo volver a la versión anterior.

¿Tienes lo básico para los usuarios y lo legal?

• Una política de privacidad y unos términos de servicio que describan lo que tu app hace y recopila de verdad. Una plantilla sirve para empezar, pero tiene que coincidir con tu app; un abogado puede revisarla.
• Un aviso de cookies o un flujo de consentimiento, si tu público y tus herramientas de analítica lo requieren.
• Una forma visible de contactarte, y una forma de que el usuario borre su cuenta o pida sus datos.
• Títulos, descripciones y una imagen para compartir en cada página, para que los enlaces se vean bien en redes.

¿Puedes medir si está funcionando?

Antes del lanzamiento, define qué es un buen primer mes, por ejemplo registros, usuarios activados o conversiones pagadas, y configura solo lo necesario para medirlo:

• Analítica en las páginas y eventos clave (registro, primera acción importante, compra).
• Una forma simple de recibir comentarios: un formulario, un correo o una encuesta corta dentro de la app.
• Una hoja de cálculo o un tablero que vas a revisar cada semana.

¿Qué haces la primera semana después de lanzar?

1. Revisa los errores todos los días. Los primeros usuarios reales encuentran problemas que ninguna prueba detectó.
2. Habla con los primeros usuarios. Cinco conversaciones enseñan más que cualquier tablero.
3. Arregla antes de construir. Pausa las funciones nuevas hasta tener bajo control los errores del lanzamiento.
4. Anota cada problema en una sola lista, con qué tan seguido pasa. Esa lista se vuelve tu hoja de ruta. Si necesitas un formato, usa nuestra guía para reportar un error a un desarrollador.

Respuestas rápidas

¿Necesito un diseño perfecto para lanzar? No. Necesitas que el flujo principal funcione, que los datos estén seguros y una forma de escuchar a los usuarios.

¿Conviene hacer una beta antes? Casi siempre sí, aunque sea pequeña. Mira cómo probar tu app con usuarios beta.

¿Qué es lo que más se olvida? La propiedad de las cuentas. Es fácil descubrir el día del lanzamiento que el dominio o la base de datos están a nombre de otra persona.

¿Con cuánta anticipación empiezo esta lista? Una o dos semanas te dan tiempo para corregir lo que aparezca.

¿Quieres otro par de ojos antes de lanzar?

Pasa el chequeo gratuito de tu app por tu URL de producción para detectar lo que se ve desde afuera. Si quieres ayuda para sacar la primera versión o mantenerla sana después, mira el desarrollo de MVP y el mantenimiento de software, o escríbenos.