Recorre la primera sesión del cliente
Crea una cuenta nueva en el entorno que piensas publicar. Sigue la verificación o los callbacks de proveedor, recarga la app, actualiza un perfil y cierra sesión. Repite el recorrido en una pantalla estrecha con el teclado. Tu sesión de desarrollo habitual puede ocultar pasos de configuración faltantes y estado obsoleto.
Revisa los avisos que explican qué hacer a continuación. Una pantalla vacía debería ofrecer una acción útil. Una petición fallida debe explicar cómo reintentar en lugar de sugerir que el trabajo tuvo éxito. Usa el lenguaje real del producto en estos avisos y asegúrate de que los enlaces de cuenta y soporte lleven a destinos reales.
Repite el recorrido una vez por cada método de inicio de sesión. Los callbacks de OAuth de Google y GitHub traen cada uno sus propias redirecciones y modos de fallo (la guía de configuración de OAuth cubre cómo configurarlos), y la pantalla de consentimiento de prueba de un proveedor se comporta distinto de la de producción.
- La creación de cuenta y la restauración de sesión funcionan.
- Cerrar sesión revoca el acceso y borra la presentación del usuario anterior.
- Los estados vacío, cargando y error siguen siendo comprensibles en móvil.
- Cada proveedor OAuth completa su callback en el dominio real.
- Los emails de verificación y restablecimiento llegan, se leen con claridad y enlazan al entorno correcto.
- La experiencia de primer uso le dice a un usuario nuevo qué hacer a continuación.
Demuestra el acceso de pago en el servidor
El checkout es la mitad fácil. Recorre todo el ciclo de vida en el sandbox del proveedor: compra, webhook recibido y verificado, permiso persistido, función de pago desbloqueada — y después renovación, cancelación y reembolso. Cada transición debe cambiar estado que posee el servidor, no solo un flag de cliente. La guía de facturación muestra dónde guarda supastack ese estado.
Después prueba los eventos que esperas no ver: un webhook entregado dos veces, un pago fallido, una suscripción que caduca en mitad de una tarea. Un permiso responde «¿está permitido ahora mismo?» en el momento de la petición; una insignia del panel no.
- Una compra en sandbox se completa y desbloquea la función de pago.
- Las entregas duplicadas de webhooks son seguras — el procesamiento es idempotente.
- La cancelación y el reembolso revocan el acceso en la frontera del servidor.
- Los límites por asiento o por uso, si se ofrecen, rechazan más allá de sus términos.
Verifica los límites con dependencias reales
Usa dos cuentas independientes para verificar la propiedad. Intenta leer y modificar el registro de una cuenta desde la otra, incluido el estado de tarea y las URL de recuperación. Comprueba el acceso de pago en la frontera de la acción de servidor, no solo ocultando un botón en la interfaz.
Los registros delimitados por espacio de trabajo son la espina dorsal de un producto multi-tenant — el post sobre fronteras de espacio explica el modelo. Sea cual sea tu stack, la pregunta de lanzamiento es la misma: ¿cada lectura y escritura deriva la propiedad del contexto autenticado del servidor, sin aceptar como prueba ningún ID de registro ni espacio enviado por el cliente?
- Las lecturas y escrituras entre espacios se rechazan.
- Las URL de recuperación y de tarea no conceden acceso por sí solas.
- Las vistas de lista y detalle aplican el mismo delimitado.
- Las claves de API y los webhooks, si se ofrecen, también llevan el ámbito del espacio.
Ejerce las rutas de fallo a propósito
El trabajo en segundo plano falla de dos maneras distintas, y cada una necesita su propio test. Un dispatch fallido deja al cliente sin saber si algo se encoló — una clave de idempotencia delimitada a la tarea y un envío guardado permiten que la recuperación reutilice la petición original en lugar de duplicarla. Una finalización fallida significa que el trabajo corrió pero el resultado nunca llegó — los reintentos y el sondeo de estado deberían cerrar ese hueco sin una segunda generación.
Aplica el mismo razonamiento a los proveedores: un timeout del proveedor de AI, un email rebotado, un error de la API de facturación. Cada uno debe terminar en un estado concreto y explicable en lugar de un medio resultado silencioso. La guía de recuperación de tareas documenta cómo lo maneja la ruta de producción del kit.
- Un reintento tras un timeout de envío no duplica trabajo ni coste.
- Una finalización fallida es visible y recuperable, no una pérdida silenciosa.
- Los errores de proveedor llegan al usuario como estados honestos, no como caídas genéricas.
Prepárate para el primer fallo
Asegúrate de que alguien pueda encontrar un error, relacionarlo con la tarea afectada y ayudar al usuario a recuperarse sin exponer secretos de proveedor. Confirma qué logs y registros de auditoría existen, cuánto tiempo los conservas y cómo accede a ellos un operador.
Decide antes del lanzamiento cómo se ve «algo va mal»: entregas de jobs fallidas, errores de verificación de webhooks, una subida repentina del gasto en proveedores. Una alerta que nadie recibe no es monitorización — la configuración de observabilidad cubre el cableado de esas señales.
Trata las copias de seguridad como un ejercicio operativo: una copia configurada no es lo mismo que una restaurada. Ejecuta la restauración una vez, sobre datos parecidos a producción, antes del día en que la necesites.
- Un error puede trazarse hasta la petición, el usuario y la tarea que lo causaron.
- Los logs y los registros de auditoría tienen un dueño, una política de retención y reglas de acceso.
- Se ha restaurado una copia de seguridad, no solo configurado.
- Los jobs fallidos y los errores de webhooks levantan una alerta que una persona recibe.
Revisa las superficies alrededor del producto
Las superficies legales y de comunicación son parte del lanzamiento, no del pulido: una privacidad y unos términos que describen lo que el producto hace de verdad, una dirección de soporte que llega a una persona y un dominio remitente verificado para que el correo transaccional llegue desde una dirección que posees.
Lee cada email automático como lo haría un cliente. Los mensajes de verificación, restablecimiento, recibo y finalización deben llevar el nombre del producto, enlaces al entorno correcto y una vía de respuesta que no sea una dirección noreply muerta.
- Las páginas de privacidad y términos describen el producto que realmente ejecutas.
- El correo transaccional se envía desde un dominio verificado que posees.
- Las preguntas de soporte y facturación tienen un destino accesible.
Haz explícita la decisión de salir o no salir
Monta el registro de lanzamiento: la revisión del build, el entorno objetivo, qué se probó y cómo, y qué sigue sin verificar. Una checklist con huecos honestos gana a un resumen confiado — los huecos son donde suele vivir el primer incidente.
Decide la ruta de rollback antes de necesitarla: cómo revertir el despliegue, qué pasa con los datos escritos entretanto y quién toma la decisión. Después lanza la versión más pequeña de la oferta que puedas soportar por completo, y amplíala deliberadamente.
Preguntas frecuentes de lanzamiento
Las checklists de lanzamiento fallan en sitios predecibles. Estas son las preguntas que atrapan a la mayoría.
- ¿Qué olvida la mayoría de lanzamientos SaaS? — Los finales de los flujos: un cierre de sesión que realmente revoca, una cancelación que realmente quita el acceso y un ensayo de restauración para la copia que existe sobre el papel.
- ¿Cuántas cuentas de prueba necesito? — Al menos dos, en el entorno objetivo. El aislamiento de datos y los flujos de invitación no se pueden verificar con una.
- ¿Pruebas en sandbox o en producción? — Ambas. El sandbox demuestra la lógica del ciclo de vida; una pequeña transacción real demuestra que claves, dominios y webhooks están cableados al sitio correcto.
- ¿Cuándo es seguro lanzar? — Cuando cada elemento que protege datos o dinero del cliente está verificado y los elementos sin verificar están anotados con dueños — no cuando la lista de funciones parece completa.
- ¿Qué cambia después del lanzamiento? — Guarda el registro de lanzamiento, vigila las alertas de fallo que configuraste y vuelve a ejecutar la checklist tras cualquier cambio significativo en auth, facturación o delimitado.