Un producto digital no se encarga entero de una vez. Se construye por fases. Cada una se presupuesta al cerrar la anterior, cuando ya se sabe lo que hay dentro.
01
Diseño de producto
Arquitectura, modelo de datos y prototipo navegable. Termina con un presupuesto en firme del MVP.
02
MVP en producción
Producto funcionando con usuarios reales dentro. No una demo: algo que se usa a diario.
03
Producto v1
Los módulos completos y el ciclo de cobro, ya con datos de uso reales para decidir qué construir.
∞
Evolución
La fase que no acaba. Quien lo construyó lo mantiene vivo.
El diseño de producto es obligatorio antes de todo MVP: es lo que
permite presupuestar con seriedad y comprometeros sin arriesgar el proyecto entero de
golpe. Se descuenta si seguís adelante.
El alcance
Un SaaS no es una pantalla.
Es un producto que usan varias empresas a la vez, cada una viendo solo sus
datos, por el que alguien paga una cuota que se repite. Eso arrastra seis piezas. Solo
una se ve, las otras cinco son las que deciden si aguanta.
Cuando aquí decimos «producto» nos referimos a las seis. Un MVP no
las lleva todas: lleva las que hacen falta para que alguien lo use de verdad, y las demás
entran en la fase siguiente. Cuál va en cuál se cierra en el diseño.
Cómo se construye
Casi todo está debajo.
Lo que se ve en pantalla es la parte pequeña. Lo que decide si un producto
aguanta a mil clientes o se cae con cien está debajo. Éste es ese trabajo, en orden:
el primero se cierra en la fase 01 y los otros tres se construyen en el MVP.
01
Se estudia la arquitecturaAntes de programar
Hay decisiones que se toman una vez. Si se toman mal, no se corrigen:
se reescribe el producto.
La principal es cómo se separan los datos de cada cliente. En un SaaS
eso atraviesa todas las tablas y todas las consultas: no es una pantalla más,
es de dónde cuelga el resto. Con ella van el modelo de datos, quién puede ver y
cambiar cada cosa, además de qué pasa cuando alguien deja de pagar. Se dibuja y se acuerda
con vosotros antes de escribir código, porque es lo que después no se puede mover.
02
Se aplican patrones conocidosNada improvisado
Casi ningún problema de un SaaS es nuevo. Los que no lo son se
resuelven con la solución que ya tiene nombre.
Cobrar cada mes, reintentar un pago sin duplicarlo, mover trabajo
pesado fuera de la espera del usuario, cambiar el modelo de datos sin parar el
servicio: cada uno de ésos es un patrón documentado. Usarlos, en vez de inventar una
solución propia, es lo que hace que el producto sea predecible y continuable.
Si mañana quisierais llevároslo a otro equipo, se encuentra con piezas que reconoce
y no con la ocurrencia de alguien.
03
La infraestructura aguantaResiliencia
Un producto que se cae el día que sale en prensa no es un producto
que aguanta. Es uno que todavía no ha tenido visitas.
El trabajo pesado —enviar mil correos, generar facturas, procesar un
fichero— no se hace mientras alguien espera delante de la pantalla: va a una cola y
lo reparten varios trabajadores. Si uno se cae, los demás siguen y ese trabajo se
reintenta. Si el uso sube, entran más máquinas; si baja, se apagan y la factura
baja con él. Las copias de seguridad se restauran de verdad una vez, no se
configuran y ya. Y las alertas suenan en el móvil de una persona concreta.
04
Se integra con lo que ya tenéisSin sustituirlo
Un SaaS nuevo no obliga a tirar las herramientas que ya funcionan.
Habla con ellas.
El cobro recurrente —que entra en la fase 3— se lleva a una pasarela
como Stripe, que se ocupa de las tarjetas: nosotros nunca las vemos ni las
guardamos. La facturación
puede ir a Holded o al programa de contabilidad que ya use la gestoría, para
que nadie copie una factura a mano. Y lo mismo con el CRM, el correo transaccional,
la firma electrónica o vuestro ERP. Cada integración se estudia por separado, porque
cada una depende de lo que permita la otra parte. Se presupuestan aparte.
Qué entra
Lo que lleva un MVP en producción.
Es la diferencia entre validar una idea y tener algo que aguante gente
de verdad dentro. Ocho cosas, casi todas en lo que no se ve.
Los flujos acordadosFuncionando con usuarios realesLos que se cerraron en el diseño, de punta a punta y en producción. No una demo: gente de fuera usándolo.
Sin que nadie les acompañeAlta autoservicioEl cliente entra, se da de alta y empieza a trabajar solo. Si hace falta que alguien de vuestro equipo lo configure a mano, no escala.
Varias empresas dentroDatos aislados por organizaciónTodas comparten la misma instalación y ninguna ve nada de otra. Es la decisión que atraviesa el modelo entero, y por eso va desde el primer día.
Quién puede tocar quéCuentas, roles y permisosCada rol ve y cambia solo lo suyo, comprobado en el servidor. Ocultar un botón no es un permiso.
Para operar sin llamarnosPanel de administración y avisosDar de alta, corregir un dato o ver qué pasó con un cliente. Y alertas que llegan al móvil de una persona concreta, no a un panel que nadie mira.
Restauradas de verdadCopias verificadasSe prueba una restauración completa antes de entregar. Una copia que nunca se ha restaurado es una carpeta de archivos, no una copia de seguridad.
Todo a vuestro nombreRepositorio e infraestructuraDesde el primer día. Si un día queréis llevároslo a otro equipo, no hay nada que desenredar ni nadie a quien pedir permiso.
Al entregarDocumentación y 60 días de garantíaCómo está montado y cómo se despliega, escrito para alguien de fuera. Y dos meses en los que lo que no funcione como se acordó se corrige sin coste.
El cobro recurrente no entra en esta fase. Se
construye en la fase 3, con planes, cambios, prorrateos e impagos, cuando ya se sabe qué
se cobra y por qué. En el MVP se comprueba que lo usan; en la siguiente, que lo pagan. Si
hace falta cobrar antes, se presupuesta aparte.
La entrega
Producción de verdad, comprobada.
El día de la entrega se repasa esta lista con vosotros delante. Es la
diferencia entre un producto y una demo que funciona.
Los flujos acordados funcionando de extremo a extremo en producción.
Alta, acceso y recuperación de contraseña operativas.
Panel de administración con las operaciones acordadas.
Copias de seguridad probadas con una restauración real, no solo configuradas.
Alertas activas que llegan a una persona concreta.
Documentación de arquitectura y de despliegue entregada.
Repositorio, infraestructura y cuentas a vuestro nombre.
Después, 60 días de garantía sobre
defectos. El código es vuestro desde el pago final.
Nuevo
¿Ya tenéis un prototipo que se rompe?
Se monta rápido con Lovable, Bolt, Cursor o no-code, funciona en la demo,
entran los primeros clientes y empieza a caerse. No está mal hecho: nunca se pensó para
aguantar usuarios simultáneos, permisos, cobros ni migraciones de datos.
Qué pasa cuando entran usuarios de verdad
prototipo producción
10 usuarios1001.000
Diagnóstico de prototipo
Una semana. Qué aguanta y qué no, dónde están las grietas de seguridad,
rendimiento y datos, además de qué costaría reconstruirlo. Se descuenta si seguís.
Ingeniería de software
Backend y arquitectura reconstruidos con estándares de producción,
conservando el producto ya validado: los flujos, la interfaz y lo aprendido de los
usuarios reales.
No parcheamos código ajeno: lo sustituimos. Lo que se
conserva es la validación, no el código.
Después
La fase que no acaba.
Un producto en producción con clientes dentro necesita a alguien
pendiente. Lo lleva quien lo construyó. Se contrata aparte y podéis empezar cuando
queráis, también más adelante.
01
390 €/mes
Monitorización, parches de seguridad, copias verificadas, respuesta en 48 horas laborables e informe mensual.
02
890 €/mes
Todo lo anterior, más cuatro horas al mes de evolutivos, respuesta en 8 horas y revisión trimestral de arquitectura.
03
1.600 €/mes
Todo lo anterior, más diez horas al mes, respuesta en 4 horas, guardia extendida y objetivos de disponibilidad acordados.
¿Y cuánto cuesta?
Está todo publicado: el precio de partida,
qué entra exactamente por él y qué mueve cada presupuesto.