Cómo lanzar un SaaS en solitario: mi stack y mi método en 2026

He lanzado varios productos yo solo. SaaS web, apps de iOS, herramientas open source. Algunos funcionan, otros no. Pero cada vez aprendo la misma lección: lo que te mata cuando trabajas solo no es la falta de ideas, es el tiempo perdido en cosas que no aportan nada.

Hoy soy CTO de CBlindspot, un SaaS LegalTech. Y en paralelo sigo enviando mis propios proyectos. Así que la pregunta de "cómo lanzar un SaaS cuando estás solo" me la hago de verdad, todas las semanas, con mi propio tiempo en juego.

Aquí va mi stack y mi método en 2026. Sin teoría. Lo que uso de verdad.

Mi stack SaaS en solitario: la elección por defecto

Cuando empiezo un producto nuevo, ya casi no pienso en el stack SaaS en solitario. Tengo un estándar, y me ciño a él salvo que haya una razón seria para desviarme. Pensar en el stack en cada proyecto ya es procrastinación disfrazada.

Mi estándar:

• Next.js + TypeScript: un único framework para el front y el back. App Router, Server Actions, API routes cuando las necesito. TypeScript en todas partes, no negociable. El tipado te salva la vida cuando eres el único que relee tu código a las 23h.
• Tailwind + shadcn/ui: ya no dibujo botones a mano. shadcn me da componentes limpios que poseo en mi repo, que modifico como quiero. Copias, adaptas, avanzas. El design system queda resuelto en un día.
• Prisma: mi ORM. El esquema es legible, las migraciones son limpias, el autocompletado es perfecto con TypeScript. Casi nunca toco SQL en crudo al principio.
• Postgres o MongoDB: Postgres por defecto para todo lo relacional (la mayoría de los SaaS). MongoDB cuando el modelo de datos es de verdad flexible o cuando prototipo rápido. No mezclo los dos por gusto.
• Vercel para el despliegue web. Haces push y está en línea. Preview deploy en cada PR. Cero configuración de servidor. Para alguien que trabaja solo, es imbatible al arrancar.
• Hetzner cuando necesito un VPS para los jobs largos, el scraping, o todo lo que se pasa de los timeouts serverless. Mi VPS Hetzner me cuesta menos de 4 € al mes y funciona 24/7. Vercel para la web, Hetzner para el trabajo sucio.

Este stack me lo sé de memoria. Ese es justo el punto. No pierdo una hora leyendo la documentación de una herramienta nueva. Codeo la feature que aporta.

Auth y pagos: no reinventes nada

Dos cosas en las que los solo founders pierden un montón de tiempo: el auth y los pagos. Es tentador codearlo todo tú mismo. No lo hagas.

Para el auth, uso una solución gestionada. NextAuth/Auth.js cuando quiero quedarme en mi repo y mantener el control, o Clerk cuando quiero tenerlo resuelto en veinte minutos con el magic link, el SSO y la gestión de sesión ya hechos. Codear tu propia gestión de contraseñas, de reset, de sesiones, es una superficie de bugs y de fallos de seguridad enorme para cero valor añadido. Nadie ha comprado nunca tu producto porque hayas codeado tu propio hashing.

Para los pagos, es Stripe en la web, RevenueCat en móvil. En mis apps de iOS (QuranWay, WallCraft AI), RevenueCat gestiona las suscripciones, las pruebas, la restauración de compra y la sincronización cross-device. Migré QuranWay a RevenueCat y eso me quitó una montaña de código casero frágil. En la web, Stripe Checkout + webhooks, punto final. Conectas el webhook que activa el flag premium en base de datos, y ya está.

La regla: todo lo que el mercado ya resuelve, lo compras. Codeas lo que te diferencia, nada más.

Trigger.dev para los jobs en segundo plano

El momento en el que los principiantes sufren es cuando hay que ejecutar código fuera de la petición HTTP. Enviar emails, generar un informe, hacer scraping, llamar a un LLM que tarda 40 segundos. Las funciones serverless de Vercel hacen timeout a los 60 segundos. Te quedas atascado.

Mi respuesta: Trigger.dev. Es un orquestador de jobs en TypeScript. Escribes tu tarea como una función, la disparas desde tu app, y se ejecuta en segundo plano con retry automático, logs, y larga duración sin problema. Para todo lo que es IA (RAG, generación, batch), es perfecto: nunca bloqueas al usuario.

Cuando el job es de verdad pesado o tiene que correr en cron permanente, lo paso al VPS Hetzner con un cron nativo. Pero en el 90 % de los casos, Trigger.dev hace el trabajo sin que yo tenga que gestionar infra.

El método: ship fast, mide, itera

El stack es el 30 % del juego. El resto es disciplina. Mi lema es "ship fast, wire AI in, don't over-engineer". Así se traduce en el día a día.

Empieza vergonzosamente simple. Tu primer despliegue tiene que ser feo e incompleto. Una landing, un signup, una feature que funciona. Si no te da vergüenza tu v1, lanzaste demasiado tarde. Tengo productos que tardaron tres semanas en ver a su primer usuario, y debería haberlo visto en tres días.

No sobre-arquitectures. Nada de microservicios. Nada de event-driven en un producto que tiene cero usuarios. Nada de abstracciones "por si acaso". Un monolito Next.js bien ordenado te lleva hasta miles de usuarios sin sudar. La arquitectura que escala la construirás cuando tengas el problema de escalar. Hoy tu problema es conseguir un cliente.

Mide antes de codear la siguiente feature. Pon analítica desde el día 1. En QuranWay tengo un hub de analítica casero que me dice exactamente dónde se cae la gente. Resultado: descubrí que mi paywall convertía al 0,58 %. Ese número me hizo repensar todo el modelo, pasar de un hard paywall a freemium. Sin los datos, habría codeado diez features inútiles pensando que el problema estaba en otro lado.

Itera sobre lo que mueve la aguja. Una vez que mides, lo sabes. Dejas de codear por instinto. Cada semana, una pregunta: ¿qué me acerca a un ingreso? Eso es lo que haces. El resto espera.

Los errores que evitar en solitario

He cometido más o menos todos estos errores al menos una vez. Aprende de los míos.

• Construir tres meses antes de enseñar nada. Te vas a enamorar de tu visión y vas a pasar por alto lo que quiere la gente. Enseña pronto, encaja los golpes pronto.
• Elegir herramientas que no conoces para ese proyecto concreto. Mantén tu stack por defecto. Un proyecto nuevo no es excusa para aprender un framework nuevo. Aprendes en side-projects desechables, no en lo que tiene que aportar dinero.
• Codear el auth y el billing a mano. Ya lo dije. Es la trampa número 1.
• Optimizar un rendimiento que nadie sufre. No tienes un problema de rendimiento con 12 usuarios. Tienes un problema de adquisición.
• Descuidar el marketing. En solitario, "build it and they will come" es falso. WallCraft AI está live en la App Store, y el trabajo de verdad empieza ahí, no antes. Reserva tiempo cada semana para la distribución, o tu producto muere en silencio.
• Hacer lo perfecto en lugar de lo terminado. El perfeccionismo en solitario es solo miedo disfrazado. Un producto terminado y en línea le gana a un producto perfecto en tu cabeza, siempre.

En resumen

Lanzar un SaaS en solitario en 2026 no es un problema técnico. El stack está resuelto: Next.js + TypeScript + Tailwind + shadcn + Prisma sobre Postgres o Mongo, desplegado en Vercel, con Hetzner y Trigger.dev para lo pesado, y auth + billing gestionados que nunca escribes tú mismo.

El juego de verdad es la disciplina. Empezar simple. No sobre-arquitecturar. Medir. Iterar sobre lo que aporta. Distribuir tanto como codeas.

Tu stack no te hará ganar. Tu velocidad para aprender de tus usuarios reales, sí. Elige herramientas aburridas que dominas, y mete toda tu energía en lo único que importa: sacar el producto, enseñarlo, y mejorarlo con datos. Ship fast. Lo demás viene solo.