Un producto digital 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, que lo usan 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
Qué hay debajo de un SaaS.
Un SaaS 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. Lo que ve el cliente es la parte
pequeña: debajo van la ingeniería y la infraestructura que deciden si aguanta.
Lo que ve vuestro cliente
app.vuestroproducto.com/pedidos
AAcme S.L.▾
Pedidos
Clientes
Informes
Ajustes
Administración
Pedidos+ Nuevo pedido
Este mes
Pendientes
Incidencias
Pagado
Pendiente
En curso
Pagado
Y la ingeniería que lo sostiene
01
Arquitectura multi-tenantCada cliente, aislado en cada consulta
organización en cada tabla
RLS en Postgres
02
API y reglas de negocioUn contrato validado y documentado
permisos en el servidor
registro de cambios
03
Trabajo en segundo planoLo pesado, fuera de la espera del usuario
cola con reintentos
webhooks idempotentes
04
Entrega continuaCada cambio, probado antes de salir
pruebas automáticas
migraciones sin parar
vuelta atrás en minutos
05
Infraestructura elástica y seguraCrece con el uso y se defiende sola
más máquinas con el uso
cifrado en reposo y en tránsito
cortafuegos y control de abuso
06
Vigilancia y copiasSi algo falla, alguien se entera
trazas y alertas
restauración probada
Nada de esto se ve en una demo. Sin ello, el producto se cae con el
primer cliente grande. Cuánto necesita el vuestro de cada capa se decide en el diseño.
Cómo se construye
El trabajo que no se ve, en cuatro pasos.
Van en orden: el primer paso se
cierra en la fase 01 y los otros tres se construyen en el MVP.
01
Se estudia la arquitecturaAntes de programar
Algunas decisiones de arquitectura no se pueden cambiar después sin
reescribir el producto. Por eso se toman antes de programar.
La principal es cómo se separan los datos de cada cliente. En un SaaS
eso atraviesa todas las tablas y todas las consultas y de ello 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
La mayoría de los problemas de un SaaS ya tienen una solución
conocida y documentada. Es la que se aplica.
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 que otro equipo pueda continuarlo.
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
La infraestructura se monta para que el producto siga funcionando cuando
el uso se dispara o un servidor se cae.
El trabajo pesado —enviar mil correos, generar facturas, procesar
un fichero— va a una cola y lo reparten varios servidores, para que nadie espere
delante de la pantalla. 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 al menos una vez. Y las alertas suenan en el móvil de una persona concreta.
04
Se integra con lo que ya tenéisSin sustituirlo
El SaaS se conecta con las herramientas que ya usáis. No hay que
sustituirlas.
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.
Seis cosas, casi todas en la parte que no se ve. Son las que hacen falta
para tener gente de verdad dentro.
Flujos base y dos de negocioFuncionando con usuarios realesRegistro, acceso y roles, más los dos flujos de negocio básicos que se cierran en el diseño, de punta a punta y en producción, con gente de fuera usándolo. Qué cuenta como flujo.
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.
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.
Qué es un flujo
Un flujo se mide por sus casos de uso.
Un flujo es el recorrido completo de alguien para conseguir algo dentro
del producto. Cuánto pesa lo dicen sus casos de uso: cada cosa que un
rol puede hacer en ese recorrido, con sus reglas, sus estados y lo que pasa cuando
algo falla. El número de pantallas dice poco.
El MVP incluye todos los flujos base (los que lleva cualquier
SaaS) y dos flujos de negocio básicos (los que hacen único vuestro producto). Un flujo
complejo no entra en ese precio: se valora en el diseño y se factura aparte.
Incluidos siempre · no restan de los dos flujos
Flujos base: los que lleva cualquier SaaS.
Registro, acceso, recuperación de contraseña, invitaciones al equipo y roles. Se
parecen en todos los productos y sin ellos no entra nadie, así que van incluidos y
no se descuentan de los dos flujos de negocio. Que vayan incluidos no quiere decir que sean pequeños: el registro solo ya son seis pasos.
Casos de uso del registro
Darse de alta por pasos
Verificar el correo
Reenviar el correo si no llega
Rechazar un enlace caducado
Impedir un correo ya registrado
Crear la organización y su administrador
Seis pasos y dos servicios. Ninguno es de vuestro negocio: por eso va incluido y no resta de vuestros dos flujos de negocio.
Flujo base: registro: Alta por pasos → Cuenta en Firebase Auth → Correo de verificación → Valida el enlace → Crea la organización → Entra al panelCuenta como flujo de negocio
Flujo de negocio básico: dentro de vuestra plataforma.
Lo que hace único vuestro producto, resuelto con vuestros propios datos y sin depender
de ningún servicio de fuera. Los dos flujos del precio de partida son de este
tamaño.
Casos de uso de un panel de tareas
Crear una tarea
Asignarla a alguien del equipo
Avisar al asignado
Cambiar su estado
Comentar y adjuntar
Ver las vencidas en el panel
Todo pasa dentro de vuestra plataforma: un flujo de este tamaño es uno de los dos del MVP.
Flujo de negocio básico: panel de tareas: Crea la tarea → Asigna responsable → Aviso al asignado → Cambia el estado → Comenta y adjunta → Panel del gestorSe valora y se factura aparte
Flujo de negocio complejo: varios sistemas que no controláis.
Cuando el recorrido cruza el frontend, el backend y servicios de terceros —pasarela
de pago, facturación, correo—, cada integración trae sus propios casos de uso: pagos que
se confirman tarde, avisos que llegan dos veces, facturas que hay que rectificar. Por eso
no entra en los dos del precio de partida: se valora en la fase de diseño contando sus
casos de uso y se factura aparte. Y si lleva cobro,
va en la fase 3 o se presupuesta aparte, como el resto del cobro. Por qué un aviso
repetido acaba en un cobro doble está contado en el artículo sobre idempotencia.
Casos de uso de una compra
Pagar con autenticación 3-D Secure
Confirmar el pago aunque se cierre la pestaña
No cobrar dos veces si el aviso llega repetido
Emitir la factura en el servicio de facturación
Enviar la confirmación con la factura
Reintentar un pago rechazado
Devolver y rectificar la factura
Cada caja ámbar es un sistema que no controláis y que falla a su manera: no entra en los dos del MVP y se factura aparte.
Flujo de negocio complejo: compra: Carrito y facturación → Pedido e intento de pago → Pasarela de pago → Webhook de pago → SaaS de facturación → Sistema de correo → Pedido confirmado → Pago rechazado
Seguridad
Muchos clientes dentro, cada uno en lo suyo.
En un SaaS conviven los datos de muchas empresas en el mismo sistema. Además de funcionar, tiene que impedir que una vea lo de otra y que se pierda algo.
Cada cliente, aisladoLos datos de cada empresa quedan separados en cada consulta, así que un fallo en una pantalla no puede enseñar lo de otra. Cómo se aísla se decide en el diseño.
Los permisos, en el servidorQuién puede ver y hacer qué lo decide el servidor en cada petición. Lo que se toca queda registrado, con quién y cuándo.
Cifrado y defensaDatos cifrados en reposo y en tránsito, cortafuegos y control de abuso frente a intentos repetidos. Dónde se alojan y bajo qué ley se decide al diseñar.
Copias que se han restauradoCopias automáticas y, antes de salir a producción, al menos una restauración real. Una copia que nunca se ha restaurado puede fallar el día que hace falta.
Cuánto dura una sesión y quién puede cerrarla también se decide en el diseño, porque condiciona el resto: está explicado en dónde se guarda la sesión.
La entrega
Producción de verdad, comprobada.
El día de la entrega se repasa esta lista con vosotros delante.
Los flujos base y los dos de negocio 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.
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, porque 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.
El código del prototipo se sustituye entero: no
trabajamos sobre código ajeno.
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
Vigilancia del servicio y sus errores, parches de seguridad, respuesta en 48 h laborables ante una incidencia e informe mensual.
02
890 €/mes
Todo lo anterior, más cuatro horas al mes para evolutivos que no abren proyecto, respuesta en 8 h y revisión trimestral de arquitectura.
03
1.600 €/mes
Todo lo anterior, más diez horas al mes, respuesta en 4 h, guardia fuera de horario y disponibilidad acordada por escrito.
Los precios están publicados.
Con el precio de partida, qué
entra exactamente por él y qué mueve cada presupuesto.