Cupón activo 
Un MVP de SaaS no es una web app con login
Construir un MVP de SaaS tiene dos tensiones que tiran en direcciones opuestas: el foco (hacer lo mínimo para validar) y la infraestructura real que un SaaS exige desde el día uno. Un MVP de SaaS de verdad necesita gestión de usuarios, infraestructura de facturación, aislamiento de datos, una arquitectura de API y un pipeline de despliegue que permita publicar cambios sin romper lo que ya está en producción. Un blog con autenticación no es un SaaS.
El spec-driven design sirve justo para manejar esa tensión: te obliga a decidir qué construir y, sobre todo, cómo, antes de escribir código. Este post va de eso: qué temas considerar, qué tecnologías elegir y qué caminos tomar.
Qué temas considerar: los cinco marcadores de un SaaS
Antes de pensar en el stack, hay cinco piezas que separan un SaaS de una web app sofisticada. Si tu MVP no las cubre, probablemente todavía no es un SaaS:
Multi-tenancy (aislamiento de datos): cómo separas los datos de un cliente de los de otro.
Facturación por suscripción: planes, cobros recurrentes, gating de features.
Gestión de usuarios y roles (RBAC): quién puede ver y hacer qué. (Role-Based Access Control o control de acceso basado en roles)
Arquitectura de API: una base limpia sobre la que el producto crezca.
Pipeline de despliegue: poder publicar sin romper lo que ya funciona.
Una buena regla para definir el alcance: suficiente infraestructura para cobrarle a un segundo cliente sin trabajo manual, y ni una feature más.
Empieza por la spec, no por el código
El spec-driven development (SDD) pone la especificación como fuente de la verdad: la escribes antes de implementar, y de ahí se derivan el código, las pruebas y la documentación. El flujo es Specify → Plan → Tasks → Implement, y cada fase produce un artefacto en Markdown que alimenta al siguiente.
Para un MVP de SaaS, la spec es donde decides lo que es caro de cambiar después:
El problema y el usuario: un segmento, un dolor concreto.
El recorrido crítico: del alta al primer momento de valor. En SaaS, la activación temprana suele decidir la retención.
El modelo de tenancy: ¿row-level isolation o una base de datos por cliente? Esta decisión va en la spec, no se improvisa.
Criterios de aceptación: cómo sabrás que cada parte funciona.
El no-alcance: lo que deliberadamente dejas fuera. Suele ser la sección más valiosa.
La ventaja extra hoy: si construyes con agentes de IA (Claude Code, Copilot, Cursor), una spec clara les da contexto estructurado en lugar de prompts sueltos, y eso reduce el retrabajo de “está hecho, pero no es lo que pedí”.
Qué tecnologías usar (decisiones con criterio)
No elijas por moda; elige por velocidad de entrega y mantenibilidad. Lo que funciona bien para un MVP de SaaS en 2026:
Base de datos. PostgreSQL es la opción por defecto: es la base de datos más adoptada (alrededor del 55%) y su Row Level Security resuelve el multi-tenancy de forma elegante. Las opciones NoSQL tipo Firestore complican un SaaS con relaciones de facturación y roles. Supabase (Postgres + auth + storage + realtime) o Neon son atajos sólidos para arrancar.
Frontend y backend. El ecosistema React domina; un stack full-stack como Next.js con un ORM como Prisma te lleva muy lejos. Empieza con un monolito modular y evoluciona a microservicios solo cuando lo necesites: el monolito te da un MVP unas tres veces más rápido, y meter microservicios, event sourcing o CQRS en un MVP añade meses para resolver problemas que aún no tienes.
Autenticación y roles. RBAC desde el inicio. Supabase Auth, Clerk o Auth0 te evitan reinventar la rueda.
Facturación. Stripe es el estándar. Intégralo antes de lanzar, no después: los planes, el gating de features y el portal de cliente son parte del MVP, no un extra.
Hosting y despliegue. Proveedores gestionados (AWS, GCP) o plataformas como Vercel para Next.js. Contenedores con Docker o serverless, con CI/CD desde el primer commit.
Observabilidad. No es opcional. Montar OpenTelemetry con un backend gestionado es medio día de trabajo que se paga solo en tu primer incidente en producción. Suma seguimiento de errores desde el día uno.
Qué caminos tomar para construirlo
Hay tres rutas, y la correcta depende de qué tan en serio va el producto:
No-code (Bubble y similares): cuesta entre 1.000 y 8.000 USD y es lo más rápido para validar, pero te topas con límites cuando el producto crece.
Código a medida: un MVP con auth, facturación y despliegue va de 15.000 a 60.000 USD; control total a cambio de más tiempo e inversión.
Build asistido por IA: los desarrollos supervisados por IA comprimen en semanas lo que antes tomaba meses y más de 100.000 USD. Es la ruta donde el spec-driven más brilla.
Una pauta práctica: arranca en modo exploración (vibe coding) para tantear, y pasa a spec-driven cuando decidas que eso que construyes va a vivir. La mayoría de los sobrecostos no vienen de programar lento, sino de decisiones de arquitectura tomadas temprano que se vuelven caras de cambiar. Por eso la spec importa.
Cuándo NO necesitas un SaaS MVP
No todo producto necesita esta maquinaria. Una herramienta interna de una sola organización, software de pago único, proyectos open-source autohospedados, productos de consumo con publicidad, o un simple prototipo de validación pueden saltarse estos marcadores, y ahí una web app es la decisión correcta.
Conclusión
Crear un MVP de SaaS es un ejercicio de disciplina: decidir qué dejas fuera y resolver las decisiones de arquitectura antes de que el código las resuelva mal por ti. El spec-driven design no es burocracia; es la forma de llegar a la implementación con el problema, el modelo de tenancy, la facturación y el alcance ya resueltos. Lo que queda después es lo divertido: construir.
Referencias
GitHub Spec Kit — Documentación (github.github.com/spec-kit)
GitHub Blog — Spec-driven development with AI
Stack Overflow Developer Survey 2025 (adopción de PostgreSQL)