Checklist de producción de SaaS:14 controles antes de salir
La checklist de producción de SaaS: 14 controles (SSL, copias, reglas de seguridad, claves secretas, rollbacks) antes de que lleguen tus usuarios reales.
Antes de que tu SaaS salga en vivo, pasa una checklist de producción de SaaS: reglas de seguridad activadas y probadas en cada tabla de la base de datos, claves secretas fuera de tu código, SSL activo, copias de seguridad verificadas y un rollback que hayas ensayado de verdad. El marketing del lanzamiento se lleva toda la atención, pero las comprobaciones poco glamurosas del go-live son las que deciden si tus primeros usuarios reales se encuentran con un producto que funciona o con una brecha de datos.
Esta es la mitad técnica del lanzamiento. La mitad de marketing (el anuncio, los canales, el impulso) es el playbook de la semana de lanzamiento. Hoy se trata de asegurarte de que lo que anuncias no se cae.
Por qué necesitas una checklist de producción
Tu producto ha vivido en un mundo indulgente: una base de datos de desarrollo que puedes borrar y reconstruir, reglas de seguridad aplicadas con holgura, mensajes de error generosos, ningún dato real de usuarios en juego. Producción es el mundo opuesto: personas reales, datos reales, seguridad estricta y ninguna segunda oportunidad con una clave filtrada o una base de datos perdida.
El peligro es que una app puede parecer terminada y estar a una casilla sin marcar del desastre. Todo lo de esta lista es invisible en una demo. Todo es existencial en producción.
La checklist de producción de SaaS de 14 puntos
Esta es la checklist que paso antes de que cualquier producto salga en vivo, traducida a lenguaje llano:
| # | Control | Por qué importa |
|---|---|---|
| 1 | Todas las migraciones de la base de datos se ejecutan correctamente | El esquema de producción coincide con lo que espera tu app: ninguna tabla que falte el primer día |
| 2 | Seguridad a nivel de fila activada en cada tabla | La propia base de datos se niega a servir los datos de un cliente a otro |
| 3 | Políticas de seguridad probadas, no solo escritas | Una política que existe pero es incorrecta se siente igual, hasta la brecha |
| 4 | Índices creados para el rendimiento | Las consultas que parecían instantáneas con 10 filas de prueba se arrastran con 10.000 reales |
| 5 | Autenticación configurada para tu dominio real | Los enlaces de registro y de restablecimiento de contraseña deben apuntar a tu sitio real |
| 6 | Buckets de almacenamiento de archivos creados con políticas de acceso | Las subidas funcionan, y los usuarios solo pueden leer sus propios archivos |
| 7 | Funciones del lado del servidor desplegadas | Cualquier lógica de backend existe de verdad en producción, no solo en local |
| 8 | Secretos configurados para esas funciones | Las claves de terceros viven en ajustes seguros, nunca en el código |
| 9 | Plantillas de email personalizadas | Los emails de confirmación y de restablecimiento llevan tu marca, no una plantilla genérica por defecto |
| 10 | Limitación de peticiones (rate limiting) configurada | Un script abusivo no puede machacar tu inicio de sesión ni inflar tu factura |
| 11 | Copias de seguridad verificadas como activas | Existen copias diarias automáticas: confirmadas, no supuestas |
| 12 | Alertas de monitorización activadas | Te enteras de los picos de errores y las consultas lentas antes de que los usuarios te escriban |
| 13 | Pool de conexiones, si hace falta | Muchos usuarios simultáneos no agotan las conexiones de tu base de datos |
| 14 | Claves de API guardadas de forma segura, nunca en el código | Una clave en tu repositorio es una clave en internet |
Cada control es una pregunta que puedes hacerle a la IA: «Demuéstrame que la seguridad a nivel de fila está activada en cada tabla y enumera las tablas donde no lo está.» No necesitas saber arreglar cada punto a mano. Necesitas negarte a lanzar hasta que cada respuesta sea sí.
12 semanasTu carrera corporativa nunca fue el planSolicita plaza en el Solopreneur Accelerator.Solicitar ahora →Los tres controles que los fundadores se saltan más a menudo
Seguridad a nivel de fila (controles 2 y 3). Es el muro entre los datos de tus clientes: la base de datos negándose, a su propio nivel, a entregar los registros del usuario A al usuario B. Es el control con el peor modo de fallo, por eso tiene su propia guía. Activada no basta; pruébala intentando leer los datos de otra cuenta y confirmando que no puedes.
Claves secretas (controles 8 y 14). Tu app tiene claves públicas (seguras en el navegador) y claves secretas (acceso total a todo). Las secretas pertenecen a los ajustes protegidos de tu proveedor de alojamiento. Si alguna vez se ha escrito una clave secreta en tu código, trátala como comprometida y rótala antes del lanzamiento.
El ensayo del rollback. No está en la lista de arriba porque es un simulacro, no un ajuste: despliega y luego practica volver a la versión anterior desde el panel de tu alojamiento. Lleva unos 30 segundos sin caída, pero solo se siente como una red de seguridad una vez que lo has hecho. Ese ensayo es también la base de desplegar sin miedo después del lanzamiento.
Controles del lado del alojamiento: dominio, SSL, entorno
Del lado del alojamiento, cuatro puntos completan el go-live. Tu dominio personalizado está conectado: los cambios de DNS tardan entre 10 y 30 minutos en propagarse. El SSL está activo, algo que tu proveedor emite gratis y automáticamente en 5–10 minutos; ningún usuario debería ver nunca un aviso de «no seguro». Las variables de entorno de producción están configuradas en el panel con valores reales, separadas de cualquier valor de staging. Y el seguimiento de errores y la analítica están encendidos, de modo que desde tu primer usuario ves qué se rompe y qué se usa: la misma fontanería que hay detrás de monitorizar tu SaaS como fundador en solitario.
Copias de seguridad y recuperación: supón lo peor una vez
En el plan gratuito de una plataforma como Supabase, las copias se hacen a diario y se conservan 7 días. El plan Pro (25 $ al mes) amplía la retención a 30 días y añade recuperación a un punto en el tiempo: restaura tu base de datos a cualquier momento, como cinco minutos antes de un mal cambio. Dedica diez minutos a escribir tu plan de recuperación mientras estás tranquilo: base de datos corrupta → restaurar la última copia y verificar. Parece paranoia hasta el día en que parece genialidad.
Cuánto cuesta todo esto: normalmente nada
La parte tranquilizadora. Los planes gratuitos son realmente de nivel producción: mi propia configuración ejecuta 3 sitios en producción con 300–500 builds y 50–100 GB de ancho de banda al mes, por 0 € de alojamiento. Las señales de que has superado lo gratuito son concretas: una base de datos de más de 500 MB, un ancho de banda por encima de 5 GB/mes o querer la retención de copias más larga; y entonces son 25 $ al mes. Para la mayoría de los productos en solitario, el plan gratuito te aguanta meses o años. La checklist cuesta una tarde. Saltártela puede costarle el negocio.
El libroThe Solopreneur RevolutionLuis Gonçalves sobre cómo crear un negocio de solopreneur con IA sin dejar tu empleo.Consigue el libro →Preguntas frecuentes
¿Qué debo comprobar antes de lanzar un SaaS?
Catorce puntos técnicos en cinco áreas: base de datos (migraciones ejecutadas, seguridad a nivel de fila activada y probada, índices en su sitio), autenticación (configurada para tu dominio real, emails con tu marca), seguridad (claves secretas fuera del código, limitación de peticiones), resiliencia (copias verificadas, un rollback de 30 segundos ensayado) y visibilidad (seguimiento de errores y alertas de monitorización activados).
¿Necesito un plan de pago para salir en vivo?
Normalmente no. Los planes gratuitos son de nivel producción: ancho de banda ilimitado en el alojamiento, copias diarias con retención de 7 días en la base de datos. Pasa al plan de base de datos de 25 $ al mes cuando superes los 500 MB de datos o quieras retención de 30 días con recuperación a un punto en el tiempo. Mis tres sitios en producción funcionan con 0 € de alojamiento.
¿Cuál es el control que más se pasa por alto?
Probar la seguridad a nivel de fila, no solo activarla. Los fundadores la encienden, no ven errores y lanzan. Pero una política incorrecta se comporta exactamente igual que una correcta hasta que alguien lee los datos de otro cliente. Antes del lanzamiento, intenta activamente acceder a datos entre cuentas y confirma que la base de datos lo rechaza.
¿Cómo funcionan las copias de seguridad para un fundador en solitario?
Automáticamente, una vez verificadas. Las plataformas gestionadas hacen una copia de tu base de datos a diario sin configuración: retención de 7 días gratis, 30 días más recuperación a un punto en el tiempo en el plan de 25 $ al mes. Tu trabajo es doble: confirmar que las copias se ejecutan de verdad antes del lanzamiento y escribir el procedimiento de restauración mientras nada está en llamas.
¿Hasta qué punto estás atrapado?
Haz el Índice de Asfixia Corporativa, la evaluación gratuita para saber si estás listo para ser solopreneur.