Cómo lanzar tu SaaS
en un fin de semana
(guía 2026)

Lanzar un SaaS en un fin de semana suena a clickbait. Lo es, en parte: no vas a construir Notion en 48 horas. Pero sí puedes salir el lunes con una versión real de tu idea, en producción, con auth, pagos y los primeros usuarios pagando. Lo he hecho 12 veces. Esta es la guía que me hubiera ahorrado los primeros 8 intentos fallidos.

El mito del "fin de semana"

Cuando la gente dice "lanzar un SaaS en un fin de semana" suele referirse a dos cosas muy distintas:

• Versión Twitter: "Hice 30k MRR en un fin de semana". Mentira o suerte de unicornio.
• Versión real: "Puse en producción un MVP cobrable que resuelve un problema concreto a un segmento concreto, listo para mostrar al mundo".

La segunda sí es posible. La primera, olvídate. El objetivo del fin de semana no es ganar dinero — es llegar al lunes con una hipótesis comprobable en producción. Lo demás vendrá después o no vendrá.

Viernes — validación brutal

El viernes por la tarde es sagrado. No abras el editor. Lo único que vas a hacer es validar que la idea merece tu fin de semana. Si no pasa el filtro, mejor el cine.

El test de las 5 conversaciones

Coge a 5 personas que encajen exactamente con el público objetivo de la idea. Nada de "es para todo el mundo". Cuanto más nicho, más fácil este paso.

Pregúntales tres cosas, en este orden:

1. "¿Cuándo fue la última vez que tuviste este problema?" — Si no recuerdan, no es un problema real.
2. "¿Qué haces hoy para resolverlo?" — Si nada, no les duele lo suficiente.
3. "¿Pagarías X€ al mes por una herramienta que lo resolviera?" — Su cara responde antes que su boca.

Si 3 de 5 te confirman el dolor y mencionan un workaround actual feo (hojas de cálculo, copy-paste, "tengo a alguien que me lo hace los viernes"), tienes algo. Si no, cambia de idea esa misma noche.

"Las ideas no son escasas. Lo escaso es encontrar una idea con un dolor real, un segmento accesible y voluntad de pago. Eso se valida hablando, no codeando."

Sábado — stack + core

Sábado a las 9:00 te sientas con la idea validada y un café. Tienes hasta las 22:00 para tener el flow principal funcionando en local. No la app entera — el flow principal.

1. El stack (no pierdas tiempo eligiendo)

Para un MVP en 48h en 2026 mi stack por defecto es:

• Next.js 15 (App Router) — frontend + API en un solo proyecto.
• Supabase — base de datos, auth y storage en un click.
• Stripe o LemonSqueezy — pagos. LemonSqueezy se encarga del IVA, Stripe es más flexible.
• Resend — emails transaccionales con plantillas decentes.
• Tailwind v4 + shadcn/ui — UI bonita sin pensar.
• Vercel — deploy en 30 segundos.

Si pasas más de 1 hora "evaluando" el stack, pierdes el fin de semana antes de empezar. Ese tiempo es exactamente lo que un boilerplate decente te ahorra.

2. Construye el "happy path" y nada más

Define el happy path: el camino feliz donde un usuario se registra, hace la acción principal y obtiene valor. Una sola ruta. Sin onboarding, sin tour, sin dashboard de admin, sin emails fancy. Solo el camino feliz.

Ejemplos de happy path para distintos SaaS:

• Convertidor de PDFs: Subir → procesar → descargar.
• Generador de imágenes IA: Login → escribir prompt → ver imagen.
• Gestor de gastos: Login → añadir gasto → ver total mensual.

Todo lo que no sea el happy path se aplaza al siguiente lanzamiento. Sin excepciones.

3. Auth y datos, pero sin sobreingeniería

Para el MVP no necesitas roles, permisos, RLS complejo o multi-tenancy. Una tabla users, una tabla con tus entidades principales y una relación. Eso es todo. Si tu MVP necesita Cassandra, no es un MVP — es ya tu segunda startup.

Domingo — pago, deploy, landing

El domingo tiene una sola regla: no añadas features. Lo que no esté el sábado por la noche se aplaza. Hoy toca pulir, cobrar y publicar.

Mañana: pago y emails

1. Crea un producto en Stripe o LemonSqueezy con un precio único o suscripción simple.
2. Conecta el webhook que marca al usuario como paid en Supabase.
3. Resend con dos emails: bienvenida y recibo. Plantillas en HTML decente, en español.

Esto, hecho desde cero, son 4-6 horas. Con un boilerplate sólido, 30 minutos.

Tarde: landing page

Estructura mínima que convierte:

• Hero: titular que prometa un resultado concreto, no una feature.
• Demo visual: screenshot, vídeo de 30s o un GIF mostrando el happy path.
• Beneficios en bullets, no features.
• Prueba social aunque sea modesta (tu Twitter, un comentario que te dieron en la validación).
• Pricing claro con un solo plan y CTA grande.
• FAQ con 4-5 preguntas reales.

Noche: deploy

git push. Vercel deploy. Compra el dominio (si no lo hiciste el viernes). Apunta el DNS. Verifica que el flujo de pago funciona de verdad: tarjeta real, compra real, email recibido. Esto cazas el 90% de bugs de producción.

Lunes — primeros 100 usuarios

Tienes algo en producción. Genial. Ahora la única métrica que importa es: ¿alguien lo usa?

El lunes por la mañana publicas en estos sitios, por orden de impacto:

1. Twitter / X: hilo con la historia del fin de semana + demo en vídeo. La narrativa "lo hice en 48h" sigue funcionando en 2026.
2. Product Hunt: si tu producto encaja en su audiencia (más en inglés que español).
3. Reddit: r/SideProject, r/SaaS, r/EmprendeRA, r/Spain según nicho.
4. LinkedIn: post largo con aprendizajes. Mejor para B2B.
5. Grupos de Telegram / Discord de indie hackers españoles. Aporta valor primero, comparte después.

Objetivo realista: 100-500 visitas el primer día, 1-5 ventas si has acertado el precio y el problema. Si no vendes nada, no es porque tu producto sea malo — es porque tu mensaje no conecta. Vuelve al viernes.

Errores que cometí los primeros 8 intentos

1. Empezar a codear el viernes sin validar. Resultado: 3 fines de semana lanzando productos que nadie quería.
2. Configurar auth desde cero "porque es educativo". Cierto. Y te come el sábado entero. Si lo necesitas educativo, hazlo el miércoles siguiente — el sábado, no.
3. Querer un dashboard de admin "minimalista pero completo". No hay tal cosa. O es mínimo o es completo. En el MVP, mínimo.
4. Olvidarte del IVA hasta el día del primer cobro. Usa LemonSqueezy o Paddle si vas a vender fuera de tu país y no quieres líos.
5. Hacer una landing "neutra" en inglés. Si tu mercado habla español, escribe en español. Convierte 2-3x más.
6. No medir nada. Pon Plausible o Umami desde el día uno. Vuelas a ciegas si no.

El truco real: no empezar de cero

El secreto que nadie te cuenta cuando ves a alguien lanzar en 48 horas no es que codeen más rápido. Es que tienen pre-resuelto todo lo que no aporta valor: auth, pagos, emails, panel, deploy. La parte donde nadie te paga por reinventar la rueda.

Esa parte se resuelve una vez (con un boilerplate o con experiencia de muchos lanzamientos) y se reutiliza para siempre. Por eso un indie con 12 productos lanza el 13º en un fin de semana — y tú, en el primero, llegas al lunes sin haber pasado del setup.

Si quieres acortar el camino, IndiePack es exactamente eso: el atajo escrito por alguien que ha lanzado 12 proyectos y se ha cansado de re-configurar lo mismo cada vez. En castellano, sin atajos turbios, y a un único pago.