Cómo construiría un SaaS - inquilinos, facturación y lo que lo convierte en producto

Un MVP responde: ¿alguien terminará este trabajo? Un SaaS responde: ¿seguirán pagando muchas empresas para que mantengamos un solo código para todas? La segunda pregunta no es «añadir Stripe y un login». Es tenencia, facturación, alta y una forma de ayudar a un desconocido a las 2 de la madrugada sin entrar por SSH en sus datos.

Cómo elegiría la stack de un MVP, ya lo he escrito. Esta es la capa siguiente: cuando la forma del negocio es software-as-a-service, qué construiría de verdad, en qué orden, y qué no copiaría de Linear o Salesforce el primer mes.

1. Primero: ¿esto es realmente SaaS?

Muchas «ideas SaaS» son un sistema a medida para un cliente con factura mensual. Puede ser un buen negocio. No es SaaS. SaaS significa: un producto, muchos inquilinos, alta autónoma o venta ligera, y el coste de añadir la siguiente empresa cerca de cero - no otro proyecto.

• SaaS: muchas organizaciones, las mismas funciones, facturación en el producto, la disponibilidad es suya.
• A medida: un comprador, flujos únicos, factura cada petición de cambio. No finja que el segundo cliente «simplemente iniciará sesión».
• Si los tres primeros clientes necesitan cada uno un fork, deje de llamarlo SaaS. Venda proyectos hasta que el solapamiento sea obvio - luego extraiga el producto.

2. La unidad del producto es el espacio de trabajo, no el usuario

Modelaría el dominio alrededor de una organización (workspace, tenant, account - elija una palabra y quédese con ella). Los usuarios pertenecen a las organizaciones. Los datos pertenecen a las organizaciones. Las facturas pertenecen a las organizaciones. Si empieza por «User tiene Projects», pasará seis meses atornillando equipos, invitaciones y «quién paga».

• La organización tiene un plan, un email de facturación y un estado: trial, active, past_due, canceled.
• La pertenencia es una fila: user + org + rol (owner, admin, member bastan al inicio).
• Cada tabla de negocio tiene org_id. Una consulta sin org_id es un error, no un atajo.
• Invitaciones en lugar de «crearles un usuario». Email, aceptación, aterrizaje en el workspace correcto.

3. Tenencia: base compartida, aislamiento estricto

Para un primer SaaS no abriría un Postgres por cliente. Una base, org_id en cada fila, y defensa en profundidad para que un WHERE olvidado no se convierta en una fuga. Una base por inquilino es para aislamiento regulado o vecinos ruidosos que ya ha medido - no para el inquilino número cuatro.

• Row-level security o un helper de consultas que inyecte siempre org_id desde la sesión - no desde el body del cliente.
• Identificadores que no se adivinen (UUID). Los /org/12/invoices/4 secuenciales son una invitación.
• Almacenamiento de archivos con prefijo org_id, URLs firmadas, nunca un bucket público de «todos los uploads».
• Esquema o base por inquilino solo si un contrato, una checklist de cumplimiento o un vecino ruidoso de verdad lo impone. Migraciones sobre 200 esquemas son un producto que no quería.

4. La facturación es una función, no un plugin para más tarde

Si nadie puede pagar, no tiene SaaS. Pondría el Checkout en el camino crítico en la semana dos, aunque el resto de la app sea delgada. Una fase «facturamos a mano» vale para los cinco primeros socios de diseño - después la tarjeta tiene que funcionar.

• Stripe Billing (o el procesador que su primer mercado usa de verdad): products, prices, customer portal, webhooks. No almacene números de tarjeta. No escriba un motor de cobro.
• Uno o dos planes, no siete. Una prueba con un final claro. Tras la prueba: solo lectura o bloqueo duro - elija uno y dígalo en la interfaz.
• Precio sobre algo que el cliente entiende: plazas, proyectos o volumen mensual. La facturación por uso es potente y fácil de fallar; empiece por una plaza o un plan fijo hasta saber qué es «uso».
• Los webhooks son la fuente de verdad de «¿está pagado?». Su base refleja Stripe (o Paddle). Un cron que adivina es cómo bloquea a un cliente que paga.

5. La stack que usaría (y en qué se diferencia de un MVP de sitio)

El valor por defecto en web sigue: Next.js, TypeScript, Tailwind, Postgres. El SaaS añade unas piezas que un sitio de marketing no necesita - y sigue sin necesitar una malla de servicios.

• Auth que entiende organizaciones: Clerk, WorkOS, Auth.js más su tabla de pertenencia - no un flag global «conectado».
• Tareas de fondo desde el día uno si algo es lento o reintentable: emails, webhooks de Stripe, exportaciones, llamadas LLM. Una cola simple (Inngest, Trigger.dev o un worker en el VPS) gana a un setTimeout en una función serverless.
• Email transaccional desde el primer minuto: invitación, recibo, «su prueba termina el viernes». Si ese mail no llega, el producto parece muerto.
• Feature flags para planes (can_export, seat_limit), no if (org.plan === "pro") repartidos en cincuenta archivos.
• Hosting: Vercel más Postgres alojado está bien hasta que un worker o la residencia de datos digan lo contrario. Una región basta. Varias regiones son un problema posterior.

6. El alta es el producto de la primera hora

Los paneles SaaS vacíos no convierten. Diseñaría la primera sesión como un trabajo, no como un tour: crear el espacio, importar o escribir el primer registro real, invitar a un compañero, ver un resultado. Tooltips sobre una tabla vacía no son un alta.

• Un workspace de ejemplo vale si es claramente falso y está a un clic de «empezar con mis datos».
• Métrica de activación: completaron el trabajo central una vez, no «se registraron». Eso mírelo. Eso venda.
• Los ajustes pueden ser feos. El estado vacío de la pantalla principal, no.

7. Operaciones: cómo dar soporte a personas a las que no conoce

El día que una organización de pago escriba «no veo mis facturas», necesita un camino que no sea SSH de producción. Añadiría un admin interno delgado antes del décimo cliente, no después del primer incidente.

• Admin: encontrar la organización, ver plan y último webhook, suplantar en solo lectura, reenviar invitación. Audite esa suplantación.
• Registros con org_id y request id. «Falló» sin inquilino no es una línea de log, es un encogimiento de hombros.
• Copias que haya restaurado una vez. De noche basta al principio; una copia no probada es un cuento que se cuenta a sí mismo.
• La página de estado puede esperar. Un email «estamos caídos, esto es lo que sabemos», no.

8. Lo que no construiría el primer año

Un gran SaaS es un museo de funciones que se pagaron después. Copiar el museo es fallar el único trabajo.

• SSO, SCIM y un cuestionario de seguridad de 40 páginas solo cuando un trato real esté bloqueado en ello. Entonces son el sprint, no una misión secundaria.
• Una API pública y un marketplace de integraciones. Un Zapier o un export CSV a menudo desbloquea al mismo comprador.
• Dominios propios por inquilino, marca blanca y un estudio de temas. Subir un logo basta para la mayor parte del B2B temprano.
• IA en todas partes. Un sitio donde el lenguaje es el trabajo (búsqueda, borradores, extracción), con un esquema y un contador facturable. No un chat en cada pantalla.

9. Una secuencia que seguiría de verdad

La misma honestidad de calendario que en un MVP, con hitos con forma de SaaS. Si una semana no tiene inquilino, pago o trabajo, no es una semana SaaS.

• Semana 0: nombrar el trabajo, el comprador, el plan, el número de corte (p. ej. cinco organizaciones de pago en 90 días o paramos). Lo que no se hace, en una página.
• Semanas 1-2: organización + pertenencia + un camino feliz en producción + Stripe test mode. Tests de aislamiento: user A no debe ver a user B.
• Semanas 3-4: facturación en vivo, invitaciones, emails, alta de estado vacío, admin delgado. Póngalo delante de empresas con nombre, no «de internet».
• Días 30-90: mirar activación y motivos de baja. Añadir la única integración o informe por el que pagan. No añadir un segundo producto.

Conclusión: alquile un trabajo, no una plataforma

Construiría un SaaS tan poco glamuroso como un MVP, más las partes que hacen que muchas empresas compartan un sistema: un espacio de trabajo, una factura, un muro entre inquilinos, una primera hora que no esté vacía, y un admin para que el soporte no sea un root shell. La stack puede seguir aburrida. El producto, no.

Si tiene un flujo que varias empresas ya le pagan por repetir, y lo quiere como producto en lugar de un montón de deploys a medida - escriba por la sección de contactos. Podemos nombrar el modelo de inquilino, el primer plan y un corte que acepte una tarjeta sin fingir ser Salesforce.