¿Puedo crear un SaaS yo solo con IA?

Puedes lanzar un MVP con un flujo central tú solo usando agentes de programación. Lo difícil no es generar código, sino mantener el alcance pequeño, darle al agente una spec escrita y probar y revisar tú mismo las rutas críticas, como los pagos y el control de acceso.

¿Qué stack tecnológico debo usar para crear un SaaS con IA?

Elige un stack común que los agentes hayan visto muchas veces: Next.js, PostgreSQL (por ejemplo Supabase), una solución de autenticación ya hecha y Stripe para las suscripciones. En un stack popular el agente se inventa menos cosas y encuentras ayuda más rápido cuando te atascas.

¿Cuál es el error multi-tenant más común en un SaaS hecho con IA?

Una consulta que olvida el filtro del tenant, de modo que un cliente ve los datos de otro. Pon un ID de tenant en cada tabla, aplica el filtro en la base de datos con row-level security y pruébalo con dos usuarios distintos.

¿Cuándo debe revisar mi SaaS hecho con IA un desarrollador humano?

Antes de que entren dinero y datos reales de clientes. Unas horas de revisión por parte de un desarrollador con experiencia sobre los webhooks de pago, la autorización, el aislamiento de datos y las migraciones cuestan mucho menos que una fuga de datos más adelante.

¿Cómo consigo que la IA configure bien las suscripciones de Stripe?

Dile al agente que el estado de la suscripción solo puede cambiar desde webhooks de Stripe con firma verificada, nunca desde la redirección del navegador tras el pago. Después dispara cada evento de webhook en local con la CLI de Stripe y pruébalo.

Crear un SaaS con IA: del MVP al primer cliente

Hoy se puede crear un SaaS con IA: un agente de programación como Claude Code o Codex puede escribir en unos días el registro, las suscripciones, un panel y una API. Pero un MVP que funcione necesita algo más que «hazme un SaaS»: un alcance recortado a un solo flujo central, una spec escrita que el agente lea en cada sesión y tests en las rutas donde viven el dinero y el aislamiento de datos. Este artículo repasa el proceso que sigo, desde el alcance hasta el despliegue.

La idea es una guía que pueda seguir alguien que programa poco o nada. Sacar un prototipo con vibe coding es fácil; lo difícil es mantener vivo un producto cuando alguien introduce una tarjeta de crédito. Por eso iré marcando dónde puedes ir rápido y dónde tienes que frenar.

1. Reduce el alcance a un solo flujo central

Los MVP rara vez mueren por el código. Mueren por el alcance. El agente escribirá lo que le pidas; el problema es que cada función que añades hay que probarla, mantenerla y depurarla.

Antes de empezar, escribe una frase: «El usuario hace ___ y obtiene ___ a cambio». Por ejemplo: «Una agencia sube las publicaciones sociales de un cliente y el cliente las aprueba desde un único enlace». Todo lo que quede fuera de esa frase pasa a la versión dos.

Una primera versión suele necesitar solo:

Registro, inicio de sesión y restablecimiento de contraseña
Una organización (tenant) con miembros invitados
Un flujo central (la frase de arriba)
Un plan de pago, suscripción mensual
Una página de ajustes sencilla y un enlace al portal de facturación

Centro de notificaciones, matriz de roles, varios idiomas, app móvil, panel de administración: más adelante. Si los clientes pagan por el flujo central, ellos te dirán qué más necesitan.

2. Escribe una spec que el agente siga

Los agentes no conservan memoria entre conversaciones. Claude Code lee CLAUDE.md en la raíz del proyecto en cada sesión; Codex y muchos otros agentes leen AGENTS.md. Escribe tus decisiones ahí y cada sesión nueva empezará con las mismas reglas. Si usas los dos agentes, mantén el contenido en un solo archivo y haz que el otro apunte a él.

Una spec útil es corta y concreta:

# Project: ApproveLink (MVP)

## Product
Agencies upload posts; the client approves or comments from one link.

## Stack
- Next.js (App Router, TypeScript), Tailwind
- Supabase: Postgres, Auth, Storage
- Stripe: one plan, monthly subscription, Checkout + Customer Portal
- Tests: Vitest (unit), Playwright (end to end)

## Rules
- Every table has organization_id; RLS is on for every table.
- Subscription status changes only from the Stripe webhook.
- Database changes only through migration files.
- Secrets live in .env.local; never in code or logs.
- Ask before adding a new package.
- After every task: pnpm lint && pnpm test

## Out of scope (for now)
Roles, i18n, mobile, admin panel.

La sección «out of scope» importa. Los agentes intentan ser útiles y añaden cosas que no les pediste; un límite escrito lo reduce de forma notable.

3. Elige el stack: apuesta por lo aburrido

Cuando trabajas con IA, el mejor stack es aquel del que el agente ha visto más ejemplos. Para este tipo de MVP yo elegiría:

Next.js + TypeScript: frontend y API en un solo proyecto. TypeScript atrapa en tiempo de compilación parte de los errores del agente.
PostgreSQL (Supabase u otro Postgres gestionado): datos relacionales, row-level security (RLS) y migraciones. Supabase además te da autenticación y almacenamiento de archivos en un solo sitio.
Autenticación ya hecha: Supabase Auth, Auth.js o Clerk. No hagas que el agente escriba desde cero el almacenamiento de contraseñas y la gestión de sesiones.
Suscripciones con Stripe: Checkout para la página de pago y Customer Portal para cambiar de plan y cancelar. Nunca construyes un formulario de tarjeta.
Vercel o una plataforma similar: despliega en cada push y da a cada rama una URL de vista previa.

Qué instalar: Node.js (LTS), pnpm, Git, una cuenta de GitHub, la CLI de Supabase, la CLI de Stripe y un agente de programación (claude o codex).

pnpm create next-app@latest approvelink --typescript --tailwind --app
cd approvelink
git init && git add -A && git commit -m "chore: empty project"

Pon la spec en la raíz de esta carpeta y haz commit de ella también.

4. El primer prompt: primero el plan, después el código

Mi primer mensaje no pide código, pide un plan. Leer y corregir un plan es mucho más barato que revertir 40 archivos mal escritos.

Read CLAUDE.md. Don't write code yet.
Produce an implementation plan for this MVP:
1. Database tables (fields, relations, RLS policies)
2. Pages and API routes
3. The Stripe flow (which webhook events, where subscription status lives)
4. 6–8 small steps in order, each with what gets tested at the end
List anything unclear as questions at the end.

Lee el plan, responde a las preguntas y actualiza la spec si hace falta. Después haz que ejecute los pasos de uno en uno:

Implement step 1 of the plan: write the migration for the organizations,
memberships and projects tables and add the RLS policies. When done,
apply the migration to the local database, write a test proving two
different users can't see each other's data, and run it. Then stop.

El «Then stop» es deliberado. Después de cada paso miro el diff y hago commit, así que cuando el agente se desvía hay un punto limpio al que volver.

5. Aislamiento de datos multi-tenant: la parte más peligrosa

El peor bug de un SaaS es «el cliente A vio los datos del cliente B». El código del agente suele parecer correcto porque lo pruebas con un solo usuario mientras construyes. El problema aparece cuando llega el segundo cliente.

Mis reglas:

organization_id en cada tabla. Sin excepciones, incluidas las tablas hijas.
Que la base de datos aplique el filtro. En Supabase/Postgres, activa RLS en todas las tablas y escribe la política en torno a las organizaciones a las que pertenece el usuario. Un where organization_id = ... en el código de la app no basta por sí solo; el agente puede olvidarlo en la siguiente consulta que escriba.
La service role key se queda en el servidor. Se salta RLS. Nunca debe llegar a código que se envíe al navegador; en Next.js, jamás la pongas en una variable NEXT_PUBLIC_.
Prueba con dos usuarios. Crea dos organizaciones y, conectado como una de ellas, intenta obtener el registro de la otra por su ID. Este test debe estar automatizado y ejecutarse en cada cambio.

Pregúntale directamente al agente: «List every place in this project that bypasses RLS». La respuesta debería ser el código de servidor que usa la service role y los webhooks; si hay más, pregunta por qué.

6. Migraciones: nunca cambies la base de datos a mano

Cuando el agente quiera añadir una columna, debe hacerlo con un archivo de migración, no haciendo clic en un panel. Con la CLI de Supabase:

supabase start                      # local Postgres (needs Docker)
supabase migration new add_projects # empty migration file
supabase db reset                   # apply all migrations from scratch
supabase db push                    # apply to the remote database

Ejecuta db reset con regularidad: si las migraciones no se aplican limpiamente desde cero, producción también tendrá problemas. Una vez en producción, lee cada migración que escriba el agente. Si ves DROP COLUMN, DROP TABLE, un UPDATE sin WHERE o un índice que bloquea una tabla grande, detente y pregunta por qué. Una migración que borra datos no se puede deshacer.

7. Prueba las rutas del dinero

No necesitas tests para todo; el tiempo de un MVP es corto. Pero estas rutas no deberían llegar a producción sin probar:

Registro → crear organización → flujo central. De extremo a extremo con Playwright.
Webhooks de Stripe. ¿Se actualiza correctamente el estado de la suscripción con checkout.session.completed, customer.subscription.updated, customer.subscription.deleted e invoice.payment_failed?
Acceso sin pago. Cuando se cancela una suscripción o falla un pago, ¿se cierra de verdad la función de pago?
Aislamiento de datos. El test con dos usuarios de antes.

Prueba los webhooks de Stripe en local así:

stripe login
stripe listen --forward-to localhost:3000/api/webhooks/stripe
stripe trigger checkout.session.completed

Un prompt para el agente:

Review the Stripe webhook route. Is the signature verified? What happens
if the same event arrives twice (idempotency)? Which table holds
subscription status? Write tests for these four events:
checkout.session.completed, customer.subscription.updated,
customer.subscription.deleted, invoice.payment_failed.
Run them and show me the result.

Un error habitual: el agente activa la suscripción en la página de «éxito» a la que Stripe redirige. Cualquiera puede abrir esa URL a mano. El estado debe cambiar únicamente desde un webhook con firma verificada.

8. Despliegue y monitorización

En una plataforma como Vercel el flujo es sencillo: sube el repositorio a GitHub, conecta el proyecto e introduce las variables de entorno en el panel. Cada pull request recibe su propia URL de vista previa; prueba los cambios ahí antes de pasar a producción.

Mi lista de comprobación antes de salir en vivo:

Variables de entorno definidas en producción; claves live y de prueba de Stripe sin mezclar
Un endpoint de webhook en vivo configurado en Stripe, con su signing secret en una variable de entorno
Migraciones aplicadas a la base de datos de producción
URLs de redirección de Supabase Auth configuradas para el dominio de producción
Copias de seguridad de la base de datos activadas

Para la monitorización, añade un servicio de seguimiento de errores como Sentry para ver los errores antes de que un usuario escriba «no funciona». Basta con decirle esto al agente: «Add Sentry to the Next.js project, capture server and client errors, and don’t attach user emails or secret values to events». Añade también una comprobación de disponibilidad sencilla.

Lo que la IA hace mal

Inventar APIs que no existen. Sobre todo con versiones nuevas de librerías. Cuando falle la compilación o los tests, pásale el error tal cual al agente y pídele que consulte la documentación oficial.
Cambiar el test para que pase. Si un archivo de tests aparece en el diff, pregunta por qué.
Añadir paquetes que no necesitas. La regla «ask before adding a package» de la spec compensa aquí.
Tragarse los errores. Los bloques catch {} vacíos hacen invisibles los fallos de pago.
Autorización en el cliente. Ocultar un botón no es seguridad; la comprobación va en el servidor y en la base de datos.
Ampliar el alcance. Revierte las funciones que llegan con un «también he añadido…» o llévalas a una rama aparte.
Perder contexto en sesiones largas. A medida que crece una conversación, el agente olvida las decisiones iniciales. Empieza una sesión nueva por paso; las decisiones duraderas ya viven en la spec. Cerrar una sesión antes de que se llene la ventana de contexto protege tanto la calidad como el coste en tokens.

Seguridad: breve pero seria

Los secretos van en .env.local. Comprueba que está en .gitignore. Si alguna vez se subió una clave en un commit, revócala y emite una nueva; borrarla del historial no basta.
Nunca pegues claves de API en el chat. El agente no necesita ver la clave, solo el nombre de la variable.
Lee los comandos que ejecuta el agente. Sobre todo rm, git push --force, comandos de base de datos y curl … | sh. Aprueba automáticamente solo acciones seguras, como leer archivos y ejecutar tests.
No apuntes el agente a la base de datos de producción. Deja que trabaje con una base de datos local o de pruebas.
Valida la entrada en el servidor. Haz que cada entrada de la API se compruebe con una librería de esquemas como Zod.
Audita las dependencias. Pásale de vez en cuando al agente la salida de pnpm audit.

Cuándo incorporar a un desarrollador humano

Si te has encontrado con alguno de estos casos, merecen la pena unas horas de revisión por parte de un desarrollador con experiencia:

Antes de cobrar el primer pago real (webhooks, estado de la suscripción, reembolsos)
Cuando los datos de clientes incluyen datos personales (RGPD y obligaciones similares)
Cuando un cliente enterprise envía un cuestionario de seguridad
Cuando tú y el agente no habéis conseguido arreglar el mismo bug en tres sesiones seguidas
Cuando empiezan los problemas de rendimiento (consultas lentas, índices que faltan)

Ten a mano la spec, la carpeta de migraciones y la salida de los tests para que la revisión sea rápida. Un proyecto escrito con un agente pero confirmado en pasos pequeños y cubierto por tests es un proyecto que un desarrollador puede entender enseguida.

Cómo lo hago con AgentVera

Todo lo anterior funciona en una sola terminal. Yo uso AgentVera para gestionar varios agentes a la vez; estas son las partes que ayudan:

Frontend y backend en worktrees separados. En el workspace abro un agente Claude Code para la API y los webhooks y un agente Codex para la interfaz, cada uno en su propio git worktree. No tocan los mismos archivos, así que no se estropean entre sí. El método se explica en git worktrees para agentes en paralelo.
El diff antes de fusionar. El panel de Git muestra los cambios de cada worktree y la revisión de código comprueba cada turno terminado. Qué buscar lo cuenta revisión de código con IA.
Ver la base de datos. Con el gestor de bases de datos abro las tablas del Postgres local y compruebo lo que el agente ha escrito de verdad; DB Guard marca las migraciones arriesgadas al final de un turno.
Vistas previas. Los entornos de vista previa dan a cada servidor de desarrollo de un worktree su propia dirección, así puedo probar dos ramas una junto a otra.
Vigilar los tokens. Cada panel muestra el tamaño del contexto en vivo; cuando se dispara, cierro la sesión y empiezo una nueva.

Esto acelera las cosas pero no sustituye a las reglas anteriores: la spec, los tests y tu propia revisión siguen importando.

Para terminar

Crear un SaaS con IA tiene menos que ver con generar código y más con dejar las decisiones por escrito y proteger las rutas críticas. Reduce el alcance a un flujo, pon las decisiones en CLAUDE.md o AGENTS.md, elige un stack aburrido y popular, aplica el aislamiento de tenants en la base de datos, prueba las rutas del dinero y configura la monitorización antes de desplegar. Que lo revise una persona antes de que entren dinero y datos reales. Si quieres ejecutar agentes en paralelo, descarga AgentVera gratis y abre tus dos primeros worktrees.