Las dos semanas antes de abrir las puertas
A finales de febrero teníamos una beta funcionando bien con ocho restaurantes y una decisión tomada: el 19 de marzo abrimos al público. Eso nos dejaba unas dos semanas y media. Se sienten cortas. Y, efectivamente, lo fueron.
No queríamos lanzar a lo grande con bombo y platillo. Queríamos lanzar tranquilo: que cualquier hostelero pudiera entrar, registrarse, pagar y empezar a trabajar sin sorpresas. Suena modesto. Implica una lista de tareas larga.
Lo que cerramos en esas dos semanas
Estas son las cosas grandes que entraron en la recta final:
- Smoke tests HTTP automatizados. Un script (
npm run smoke:http) que comprueba que las rutas críticas devuelven el código correcto tras cada despliegue. Nada sofisticado, pero suficiente para detectar caídas tontas. - Cobertura E2E mínima. Tres flujos críticos verificados manualmente antes de cada release: registro completo, creación de reserva pública, edición y publicación de carta.
- Página legal completa. Términos de servicio, política de privacidad, aviso de cookies. Trabajamos con un abogado especializado en SaaS para no copiar plantillas dudosas. Pasarlo por alto no era opción.
- Billing con Stripe portal. No reinventamos la rueda: el portal de cliente de Stripe gestiona suscripciones, métodos de pago, facturas. Nosotros nos limitamos a integrar checkout y webhooks.
- Hardening de seguridad. Auditoría de políticas RLS, revisión de roles de servicio, rotación de secretos, alertas en errores 500. Lo aburrido pero imprescindible.
El día que casi rompemos la base de datos
Hubo un susto, claro. A cuatro días del lanzamiento, una migración tocó una tabla grande y bloqueó las consultas durante 90 segundos. En producción real eso es una eternidad. La beta lo notó pero nadie estaba haciendo nada crítico en ese momento. Decisión inmediata: a partir de ahí, ninguna migración se aplica sin un plan de rollback escrito y revisado por dos personas.
Esa norma sigue vigente hoy.
Lo que dejamos fuera a propósito
La tentación de añadir "una funcionalidad más" antes de lanzar es enorme. Tuvimos que decir que no a varias cosas:
- Modo oscuro completo. Los estilos estaban listos pero no probados a fondo.
- Integración con TheFork. Sabíamos que íbamos a hacerla, pero no en el día 1.
- App nativa móvil. La web responsive cubría el 95% de casos.
- Marketing automatizado por SMS. Email primero, SMS después.
Todo eso terminó saliendo en las semanas siguientes, como puedes ver en las entradas posteriores de este blog.
El día anterior
La noche del 18 de marzo activamos los pagos en producción, hicimos un último despliegue y dejamos correr los smoke tests. Cero errores. Apagamos el portátil con esa sensación rara de que has llegado a la línea de salida después de haber corrido medio maratón. El lanzamiento real, con sus propias historias, lo cuenta la primera entrada de este blog: "Hola mundo".
A partir de ese día, RestaPro dejó de ser un proyecto y empezó a ser una herramienta usada por gente real cada noche.