Cómo lanzar un SaaS en 3 meses sin morir en el intento

Tres meses parece poco tiempo para lanzar un SaaS. No lo es, si se toman las decisiones correctas desde el principio. En este artículo describimos el proceso que seguimos para llevar productos de software de cero a producción en 12 semanas: qué stack elegimos, qué arquitectura adoptamos en las primeras versiones y qué errores cometemos cuando nos alejamos de estos principios.

El principio más contraintuitivo: empieza por el monolito

La tentación en todo proyecto SaaS es diseñar microservicios desde el primer día. Es un error casi universal. Los microservicios añaden complejidad operacional que solo tiene sentido cuando ya conoces exactamente dónde están los cuellos de botella de tu sistema. En semana uno, no lo sabes.

Un monolito bien estructurado puede escalar hasta los primeros miles de usuarios activos sin problemas. Y lo más importante: se construye dos o tres veces más rápido que una arquitectura distribuida. En un lanzamiento en 3 meses, esas semanas cuentan.

El stack que usamos para llegar a producción rápido

• Next.js (App Router): frontend, API routes y SSR en un solo repositorio. Elimina la fricción de mantener dos proyectos separados en las fases iniciales. El equipo trabaja en el mismo contexto y los deploys son más simples.
• Supabase: base de datos PostgreSQL gestionada, autenticación, almacenamiento de archivos y funciones edge. Sustituye 3–4 servicios independientes con una sola integración. El coste en producción empieza en 0 € y escala con el uso.
• Vercel: despliegue continuo desde GitHub, previews automáticas por PR y CDN global incluido. La infraestructura de un equipo senior por el precio de un plan gratuito hasta cierto volumen.
• Stripe: pagos, suscripciones, trials y portal de cliente. No construyas tu propia lógica de billing. Stripe ya ha resuelto todos los casos de borde que encontrarás y los que aún no has imaginado.
• Resend o Postmark para emails transaccionales: onboarding, confirmaciones, notificaciones. Simple, fiable y con buenas tasas de entrega desde el primer día.

Este stack permite lanzar con una infraestructura que cuesta entre 0 y 50 €/mes hasta los primeros cientos de usuarios. Cuando el negocio crece, cada componente escala de forma independiente y los costes crecen proporcionalmente al valor generado.

Las 12 semanas en la práctica

• Semanas 1–3 (Discovery y diseño): definición del problema, usuarios objetivo y propuesta de valor mínima. Mapa de funcionalidades clasificadas por impacto y esfuerzo. Diseño de los flujos clave en Figma: alta fidelidad solo para las pantallas del camino crítico.
• Semanas 4–8 (Desarrollo del MVP): implementación de las funcionalidades del camino crítico. Autenticación, core del producto y flujo de pago. No se construye nada que no esté en el camino crítico del usuario que paga.
• Semanas 9–10 (Beta privada): acceso a 10–20 usuarios reales. El objetivo no es encontrar bugs (aunque se encuentren), sino validar que los usuarios llegan al valor central del producto sin fricción. Cualquier cosa que frene ese camino es prioritaria.
• Semanas 11–12 (Hardening y lanzamiento): correcciones de la beta, ajuste de mensajes, configuración de analytics y alertas de errores. Deploy a producción con el primer segmento de usuarios reales.

Lo que ralentiza más los lanzamientos

En nuestra experiencia, los proyectos que se retrasan no lo hacen por razones técnicas. Lo hacen porque el scope crece durante el desarrollo. Una funcionalidad que «solo tarda dos días» aparece en semana 6 y desplaza trabajo que estaba planificado para el lanzamiento.

La solución es tener un backlog de funcionalidades post-lanzamiento claro desde el primer día. Cuando aparece una idea nueva, va al backlog, no al sprint actual. Esa disciplina, más que cualquier decisión técnica, es lo que separa los proyectos que llegan a tiempo de los que no.

El segundo factor de retraso es la perfección prematura. En semana 3 no hace falta que el onboarding sea perfecto, ni que el dashboard tenga todas las métricas posibles. Hace falta que el usuario pueda hacer la cosa principal que vino a hacer. Lo demás puede esperar.

Cuándo usar un stack diferente

Este stack tiene un sesgo claro: está optimizado para equipos que dominan JavaScript y TypeScript. Si tu equipo trabaja principalmente en Python, Django con htmx y Railway o Fly.io puede ser una combinación igualmente válida. El mejor stack es el que tu equipo conoce bien, no el que está de moda.

Hay casos donde Next.js no es la elección correcta: productos con muchos cálculos en tiempo real (considera WebSockets nativas o servicios especializados), aplicaciones con requisitos de acceso a hardware (considera Electron o aplicaciones nativas) o proyectos con equipos grandes y módulos muy independientes (donde los microservicios pueden justificarse desde el inicio).

La decisión técnica más importante en un lanzamiento en 3 meses no es el framework: es qué funcionalidades no vas a construir en la primera versión.

El primer día después del lanzamiento

Lanzar es el principio, no el final. La semana 13 es la más importante: monitorizar los primeros usuarios reales, hablar con ellos directamente y entender qué parte del producto no funciona como se esperaba. Los mejores SaaS no son los que tuvieron el mejor diseño inicial; son los que aprendieron más rápido de sus primeros usuarios y actuaron sobre ese aprendizaje.