Las pantallas son el 20% del trabajo. Crear un SaaS a medida es sobre todo lo que hay debajo: separar los datos de cada cliente, cobrar todos los meses, facturar bien y sostenerlo cuando algo falla un domingo. Yo opero dos.
Un SaaS no es una web con login. Es un producto que cobra sin que nadie lo toque y que tiene que aguantar a clientes que no se conocen entre sí. Esto es lo que lleva dentro:
Esto no es teoría. Es la lista de lo que he tenido que construir y mantener en Libélula CRM y Tortoise, mis dos productos en producción con clientes de pago. Cada punto está ahí porque me ha costado algo aprenderlo.
Hay cuatro cosas que se deciden en la primera semana y que condicionan el producto durante años. Vale la pena pensarlas despacio:
Una base de datos por cliente o una compartida con el identificador en cada tabla. La segunda es más barata de operar y la más habitual; la primera aísla mejor y a veces la exige el cliente. Cambiar de una a otra con clientes dentro es un proyecto en sí mismo.
Cobras por usuario, por empresa, por uso, por volumen. Parece una decisión comercial y es técnica: define cómo se cuenta todo lo demás y aparece en cientos de sitios del código.
¿Se borra, se congela, se conserva un tiempo? Es una decisión legal además de técnica, y afecta a las copias, a la exportación de datos y a la posibilidad de recuperar clientes.
En cuanto un cliente tiene equipo, aparecen roles y permisos. Meterlos desde el principio cuesta poco; añadirlos con el producto en marcha obliga a revisar cada pantalla.
El error más caro es construir doce funciones antes de que exista un cliente. El orden que funciona es este:
1. Un circuito completo, para un solo tipo de usuario. Que alguien pueda registrarse, hacer la cosa principal que tu producto promete y ver el resultado. Sin planes, sin equipo, sin facturación. Solo eso, funcionando.
2. Ponerlo delante de gente real. Cinco personas del sector usándolo de verdad te dicen en dos semanas lo que ninguna reunión de producto va a decirte.
3. Cobrar. Solo cuando alguien ha dicho que pagaría. Aquí entran planes, suscripción y facturación — y ahora ya sabes qué debe incluir cada plan porque lo has visto.
4. Lo que pidan. Equipos, permisos, integraciones, informes. En el orden en que los clientes los pidan, no en el que estaban en el documento inicial.
Si el producto que quieres construir es más una herramienta interna que un SaaS que vas a vender, mira mejor software a medida o automatizar procesos de tu empresa: sale bastante más barato porque te ahorras todo lo de cobrar y separar clientes.
Una primera versión con el circuito principal funcionando y usuarios reales probándolo suele estar en semanas. Lo que alarga el proyecto es el resto: suscripciones, facturación, planes, permisos de equipo y panel de administración. Por eso conviene facturar solo cuando alguien ya ha dicho que pagaría.
Es lo que recomiendo. Validas primero que el producto resuelve algo con usuarios reales y añades la suscripción después, cuando ya sabes qué debe incluir cada plan. Montar la facturación antes de tener claro qué vendes suele significar rehacerla.
Node.js, React, Python y MySQL — el mismo conjunto con el que están construidos mis dos productos en producción. Es tecnología estándar y muy extendida, lo que significa que puedes encontrar a otro desarrollador que la continúe sin problemas.
Se implementa según lo que aplique a tu caso concreto, que depende de a quién factures y desde dónde. Es una parte que hay que definir bien antes de programarla, no improvisarla al final: rehacer la facturación de un SaaS con clientes dentro es de lo más caro que existe.
Un SaaS no se entrega y se acaba: hay que vigilarlo, hacer copias, resolver incidencias y evolucionarlo. Puedo llevarlo yo con un acuerdo mensual o dejarlo documentado para tu equipo. Lo que no recomiendo a nadie es poner un producto de pago en producción sin plan de mantenimiento.