Desarrollo SaaS en Marruecos
SaaS es tenancy, facturación, onboarding y permisos — aislamiento de datos y jobs, suscripciones y un admin donde operar de verdad.
BROC ServiceOS y MatarTaxi son ejemplos de este tipo de producto: multi-tenant, operativo y pensado para funcionar cada día.
El aislamiento es la parte fácil de hacer mal pronto y cara de arreglar después: un identificador de tenant en cada tabla, consultas con scope por defecto y no por disciplina, y jobs en cola — exportaciones, lotes de notificaciones — etiquetados para que el retraso de un tenant no retrase a otro. BROC ServiceOS aísla así los datos, jobs y archivos de cliente, de modo que el mismo despliegue sirve a muchos negocios de servicios sin que ninguno vea los clientes o facturas de otro.
La facturación se conecta a Stripe desde el primer día: los planes de suscripción mapean a límites reales del producto, no solo a un precio, y los eventos de webhook mantienen el acceso de un tenant al día cuando sube, baja o caduca. El onboarding está pensado para llevar rápido a un nuevo tenant a un espacio usable — creando su primer equipo o su primer job — en vez de dejarlo frente a un dashboard vacío sin guía.
MatarTaxi aplica la misma forma a operaciones en tiempo real en vez de administración de back-office: estado dirigido por WebSocket en lugar de refresco periódico, porque un despachador o un operador de flota necesita ver un cambio en el momento en que ocurre, no treinta segundos después.
Problemas de negocio
- Una app mono-tenant con una tabla de tenants pegada después, así que el aislamiento depende de una convención y no del propio esquema de la base de datos.
- Billing que no mapea límites que el producto aplica, así que un cliente puede pagar por un nivel que el producto no restringe de verdad.
- Un onboarding que deja a un cliente nuevo en un dashboard vacío sin datos ni guía, así que los primeros diez minutos deciden si vuelve.
- Una página de precios que promete límites que el producto no tiene forma de aplicar realmente, así que ventas hace una promesa que ingeniería tiene que remendar después.
- La exportación de datos de un tenant tratada como un favor manual puntual en vez de una función real, así que un tenant que quiere irse — o solo tener una copia — tiene que pedirlo y esperar.
- Sin rastro de auditoría de quién cambió el plan o el acceso de un tenant, así que una disputa de facturación no tiene ningún registro que consultar.
Proceso de desarrollo
- Aislamiento primero: datos, colas, archivos. Luego onboarding, planes, admin — en ese orden, porque añadir el aislamiento después del lanzamiento significa tocar cada tabla.
- Laravel + React desde Tánger, operados con Docker y copias, para que la plataforma sobreviva a un mal deploy o un servidor caído sin perder los datos de un tenant.
- Conectar los eventos de suscripción de Stripe a feature flags reales, no solo a un nombre de plan, para que bajar de plan realmente quite el acceso en vez de solo cambiar una etiqueta.
- Modelar planes y límites como datos, no como if dispersos por el código, para que un nuevo nivel de precios sea una fila en la base de datos, no un deploy.
- Registrar cada cambio de plan y permiso con quién lo hizo y cuándo, para que soporte pueda responder «por qué este tenant tiene acceso a X» sin adivinar.
- Construir la exportación de datos por tenant como una función real desde el inicio, no un favor manual, para que un tenant pueda sacar sus propios datos sin abrir un ticket de soporte.
- Limitar tasa y recursos de los tenants de prueba por separado de los de pago, para que una cuenta gratuita no pueda degradar el servicio de clientes que realmente pagan.
- Rastrear el uso de funciones por tenant desde el inicio, para que los niveles de precios y el roadmap se construyan sobre lo que los tenants realmente hacen, no suposiciones.
Qué obtienes
- Una plataforma que el segundo cliente no puede tumbar, porque el aislamiento se diseñó desde la primera tabla, no se añadió tras un incidente.
- Un onboarding lo bastante rápido para que un tenant nuevo esté trabajando en su primer job o su primer equipo minutos después de registrarse.
- Un modelo de precios que el producto realmente aplica, así que lo que promete ventas y lo que entrega la plataforma es lo mismo.
- Soporte puede responder preguntas de acceso y facturación desde el registro de auditoría en vez de pedirle a un ingeniero que revise la base de datos.
- Tenants que pueden exportar sus propios datos bajo demanda, lo que también hace que las solicitudes de RGPD y similares sean un trámite normal en vez de una carrera contrarreloj.
- Una señal de cancelación detectada temprano, porque los datos de uso muestran a un tenant quedándose callado semanas antes de cancelar de verdad, no después.
Proyectos seleccionados
FAQ
Can you integrate Stripe?
Yes. Subscriptions, webhooks, dunning-safe billing events and tenant plans mapped to real product limits.