SaaS Development in Morocco
SaaS work is tenancy, billing, onboarding and permissions — not just a login screen. I design isolation (data and jobs), subscription flows, and an admin surface operators can live in.
BROC ServiceOS and MatarTaxi are examples of this shape of product: multi-tenant, operational, and meant to run every day.
Isolation is the part that is easy to get wrong early and expensive to fix later: a tenant identifier on every table, scoped queries enforced by default rather than by discipline, and queued jobs — exports, notification batches — tagged so one tenant's backlog cannot delay another's. BROC ServiceOS isolates client data, jobs and files this way, so the same deployment can serve many service businesses without any of them seeing another's clients or invoices.
Billing is wired to Stripe from day one: subscription plans map to actual product limits, not just a price, and webhook events keep a tenant's access current as they upgrade, downgrade or lapse. Onboarding is built to get a new tenant into a usable workspace fast — creating their first team or first job — rather than dropping them into an empty dashboard with no guidance.
MatarTaxi is the same shape applied to real-time operations rather than back-office administration: WebSocket-driven state instead of periodic refresh, because a dispatcher or a fleet operator needs to see a change the moment it happens, not thirty seconds later.
Business problems
- A single-tenant app with a tenants table glued on later, so isolation is enforced by convention instead of by the database schema itself.
- Billing that does not map to limits the product actually enforces, so a customer can be charged for a tier the product does not actually gate.
- Onboarding that dumps a new customer into an empty dashboard with no data and no guidance, so the first ten minutes decide whether they come back.
- A pricing page that promises limits the product has no code path to actually enforce, so sales makes a promise engineering has to retrofit.
- Tenant data export handled as a one-off manual favor instead of a real feature, so a tenant who wants to leave — or just wants a backup — has to ask and wait.
- No audit trail for who changed a tenant's plan or access, so a billing dispute has no record to check against.
Development process
- Isolation first: data, queues, files. Then onboarding, plans, admin — in that order, because retrofitting isolation after launch means touching every table.
- Laravel + React from Tangier, operated with Docker and backups, so the platform survives a bad deploy or a failed server without losing a tenant's data.
- Wire Stripe subscription events to real feature flags, not just a plan name, so downgrading a tenant actually removes access instead of just changing a label.
- Model plans and limits as data, not as if-statements scattered through the codebase, so a new pricing tier is a database row, not a deploy.
- Log every plan and permission change with who did it and when, so support can answer 'why does this tenant have access to X' without guessing.
- Build tenant-level data export as a real feature from the start, not a manual favor, so a tenant can get their own data out without opening a support ticket.
- Rate-limit and resource-cap trial tenants separately from paid ones, so a free account cannot degrade service for customers who are actually paying.
- Track feature usage per tenant from the start, so pricing tiers and the roadmap are built on what tenants actually do, not assumptions.
What you get
- A platform the second customer cannot take down, because isolation was designed in from the first table, not patched in after an incident.
- Onboarding fast enough that a new tenant is working inside their first job or first team within minutes of signing up.
- A pricing model the product actually enforces, so what sales promises and what the platform delivers are the same thing.
- Support can answer access and billing questions from the audit log instead of asking an engineer to check the database.
- Tenants who can export their own data on demand, which also happens to make GDPR and similar requests a non-event instead of a scramble.
- A churn signal caught early, because usage data shows a tenant going quiet weeks before they actually cancel, not after.
Selected projects
FAQ
Can you integrate Stripe?
Yes. Subscriptions, webhooks, dunning-safe billing events and tenant plans mapped to real product limits.