Cómo crear un SaaS desde cero: las piezas que no se ven
Un SaaS no es solo una aplicación con usuarios: muchos clientes la comparten, pagan cada mes y ninguno puede ver los datos de otro. Lo que decide si funciona es lo que no se ve: aislamiento de datos, alta y cobro, roles, pruebas, copias y despliegues sin cortes.
Crear un SaaS desde cero es construir una aplicación que muchos clientes usan a la vez, que pagan por suscripción y en la que ninguno ve los datos de otro. Los pasos: validar la idea, prototipar, diseñar el aislamiento de datos, construir el alta y el cobro, definir roles, montar pruebas y copias, y lanzar pequeño.
Qué tiene un SaaS que no tiene una aplicación normal
Una aplicación hecha para una empresa tiene un solo cliente. Un SaaS tiene muchos, que comparten la misma plataforma y no deben enterarse unos de otros. Eso cambia casi todo:
| Aspecto | Aplicación para una empresa | SaaS |
|---|---|---|
| Clientes | Uno | Muchos a la vez, en la misma plataforma |
| Datos | Todos del mismo dueño | Cada dato pertenece a un cliente y los demás no pueden verlo |
| Altas | Las hace el equipo técnico | El cliente se registra solo |
| Cobro | Una factura por proyecto o por mantenimiento | Suscripción con renovaciones, impagos y cambios de plan |
| Cambios | Se publican cuando le conviene a ese cliente | Cada cambio llega a todos a la vez |
| Soporte | Conoces a cada usuario | Usuarios que no conoces y que deben resolver solos lo básico |
Cómo crear un SaaS desde cero: los pasos en orden
- Valida que alguien pagaría: conversaciones con clientes potenciales y un prototipo navegable antes de escribir código.
- Define el mínimo: la versión más pequeña que resuelve el problema y por la que alguien pagaría. Lo desarrollamos en qué es un MVP de software.
- Diseña el aislamiento de datos: cómo se separa cada cliente, antes de crear la primera tabla.
- Construye el recorrido completo de alta y cobro, aunque la aplicación todavía haga poco.
- Define roles y permisos: quién ve y quién hace qué dentro de cada cliente.
- Monta la red de seguridad: pruebas automáticas, copias con restauración probada y despliegues que no corten el servicio.
- Lanza pequeño y amplía con lo que te digan los primeros clientes.
Los pasos 3 a 6 son las piezas que no se ven en una demo. También son las que más caro sale arreglar después, así que el resto del artículo va de ellas.
Multi-tenant y datos aislados: la decisión que no se aplaza
Que varios clientes compartan una misma aplicación se llama multi-tenant. En la práctica significa que cada dato lleva la marca de su cliente y que cada consulta tiene que filtrar por ella. Confiar solo en que el código «siempre filtra» funciona hasta el día en que alguien lo olvida en un listado, una exportación o un informe.
Por eso conviene que sea la propia base de datos la que imponga el aislamiento. PostgreSQL, por ejemplo, permite políticas de seguridad por fila: con la protección activada y sin una política que dé acceso, no se ve ni se modifica ninguna fila. Ojo con una excepción: los superusuarios, y normalmente también el dueño de la tabla, se la saltan, así que la aplicación no debe conectarse con esas cuentas. En nuestros productos, los datos de cada cliente están aislados en la propia base de datos, y hay pruebas automáticas que intentan leer datos ajenos y deben fallar.
No es una preocupación teórica: el control de acceso roto ocupa el primer puesto del OWASP Top 10 de 2025, una referencia habitual sobre riesgos de seguridad en aplicaciones web. El detalle técnico, con los tres modelos de aislamiento, está en SaaS multi tenant.
Alta, planes y cobro recurrente
El recorrido de un cliente nuevo tiene más pasos de los que parece: registro con verificación del correo, aceptación de las condiciones (guardando qué versión aceptó y cuándo), periodo de prueba si lo hay, elección de plan, pago y, por último, qué ve y qué no según su plan. Cada paso es un punto donde se pierden clientes, así que diseñarlo es parte del producto, no un trámite.
Cobrar la primera vez es fácil con una pasarela de pago. Lo delicado viene después. Y hay un detalle técnico que evita muchos disgustos: el sistema debe enterarse de cada cobro por el aviso verificado de la pasarela, no por lo que diga el navegador del cliente. Esos avisos pueden llegar repetidos o desordenados; la documentación de Stripe, por ejemplo, lo advierte de forma expresa.
| Caso | Qué debe estar decidido antes de que ocurra |
|---|---|
| La tarjeta falla en la renovación | Cómo se avisa al cliente, cuándo se reintenta y cuántos días mantiene el acceso |
| Cambio de plan a mitad de periodo | Si se prorratea y cómo se refleja en la factura |
| Cancelación | Hasta cuándo conserva el acceso y cómo exporta sus datos |
| El aviso de pago llega dos veces | Reconocerlo y no activar ni facturar dos veces |
| Cada cobro | Su factura, con la numeración y los datos que correspondan |
Roles, permisos y portales
Dentro de cada cliente también hay fronteras. El dueño ve la facturación; el empleado, su agenda; y a veces el cliente final de tu cliente entra en su propio portal. Hemos construido portales así para inquilinos, conductores, atletas y clientes que consultan su facturación. Diseñar los roles al principio es barato; añadirlos cuando ya hay datos mezclados no lo es.
Otro recorrido que se olvida: recuperar el acceso. Si un cliente no puede volver a entrar solo, te escribirá a ti, y ese correo llegará en el peor momento.
Pruebas, copias y despliegues sin cortar el servicio
En un SaaS siempre hay alguien usándolo, así que no existe la ventana de mantenimiento cómoda. Tres prácticas que hemos aprendido operando nuestros propios productos:
- Pruebas automáticas en cada entrega. Son la primera puerta de cualquier cambio, incluido el «arreglo pequeño».
- No publicar a ciegas. Una comprobación automática impide publicar una versión nueva si un local está cobrando o acaba de abrir un ticket. Y antes de sustituir la versión en marcha se comprueba que la nueva arranca de verdad: que la vieja responda no prueba que la nueva funcione.
- Copia antes de tocar datos. Copia de seguridad antes de cualquier cambio en la base de datos, con migraciones pequeñas y reversibles. Una copia que nunca se ha restaurado es solo una suposición.
Súmale lo que tus clientes te pedirán tarde o temprano: registro de quién hizo qué, constancia del consentimiento y la posibilidad de exportar o anonimizar los datos de un cliente cuando corresponda. Nada de esto luce en una demo; todo se nota el día que falta.
Qué medir desde el primer mes
Un SaaS se mide distinto que una tienda o un proyecto a medida. Cinco números bastan para saber si vas bien:
- Altas: cuántos empiezan y de dónde vienen.
- Activación: cuántos llegan a usar lo esencial, como su primera ficha, su primera reserva o su primera factura.
- Conversión: cuántos pasan de la prueba al pago.
- Bajas e impagos: cuántos se van cada mes y por qué.
- Soporte: qué preguntan, porque cada pregunta repetida es una pantalla mal resuelta.
Si la plataforma no guarda el origen de cada alta desde el primer día, no sabrás qué canal funciona. Es de lo primero que hay que preparar.
Errores frecuentes al crear un SaaS
- Construir durante meses sin que un solo cliente lo pruebe.
- Dejar el cobro recurrente «para el final» y descubrir sus casos raros con clientes dentro.
- Añadir permisos y aislamiento después, cuando ya hay datos mezclados.
- Publicar sin pruebas porque «es un cambio de nada».
- Creer que la IA toma estas decisiones por ti. Acelera el código, pero no decide cómo se aíslan los clientes ni qué pasa con un impago; lo contamos en crear un SaaS con IA.
Hemos recorrido este camino con nuestros propios productos: InmoCenter para inmobiliarias, Entrenify para entrenadores, isoMenú para restauración y XBarber para barberías y peluquerías. Alta autoservicio, planes, cobro con tarjeta, portal del cliente y datos aislados por cliente son las piezas que hemos construido en ellos. Más sobre cómo trabajamos en desarrollo de SaaS a medida.
Para poner números a tu idea antes de empezar, repasa de qué depende lo que cuesta crear una plataforma web.
Fuentes consultadas
Comprobadas el 26 de septiembre de 2026. Enlazamos la fuente original para que puedas consultar el texto vigente.
- PostgreSQL Documentation: Row Security Policies. PostgreSQL Global Development Group.
- OWASP Top 10:2025 · A01 Broken Access Control. OWASP.
- Stripe: recibir eventos de Stripe en tu punto de conexión de webhook (duplicados y orden). Stripe (documentación oficial).
Preguntas frecuentes
¿Hace falta que un SaaS sea multi-tenant desde el principio?
Sí, o al menos hay que decidir desde el primer día cómo se separan los datos de cada cliente. Es la decisión más difícil de cambiar después: rehacerla con clientes dentro es caro y arriesgado.
¿Se puede crear un SaaS sin programar?
Las herramientas sin código sirven para validar una idea con los primeros usuarios. El límite llega con lo que no se ve: aislamiento entre clientes, casos del cobro recurrente, permisos finos, copias y despliegues. Si la idea funciona, conviene saber desde el principio cómo migrarías.
¿Qué tecnología usar para crear un SaaS?
La que tu equipo sepa mantener y que permita tres cosas: imponer el aislamiento de datos en la base de datos, cobrar con una pasarela que avise de cada evento y probar automáticamente cada cambio. El lenguaje importa menos que esas garantías.
¿Cuánto cuesta crear un SaaS desde cero?
Depende de las piezas: cuántos roles y portales, qué integraciones, cómo se cobra y qué nivel de soporte necesitas. Sin un alcance cerrado, cualquier cifra es una suposición; por eso conviene analizarlo primero y pedir una propuesta cerrada.
¿Qué debo validar antes de construir?
Que alguien pagaría por resolver el problema, cuánto y con qué frecuencia. Un prototipo navegable y conversaciones con clientes potenciales validan más que meses de desarrollo.
¿Algo de esto encaja con tu negocio? Cuéntanos cómo lo haces hoy.