Multi-tenant SaaS development
Turning a working product into a product you can sell many times is mostly one hard question: how do you guarantee tenant A can never see tenant B's data? I answer it at the database level, then build billing, plan gating and onboarding on top of that guarantee.
Built for these situations
- Service businesses productising an internal tool they already use daily
- Founders launching a vertical SaaS for a MENA industry
- Teams whose current product isolates tenants in application code and knows it is risky
- Products whose users work in poor connectivity and need offline-first clients
Not a fit if
- Single-customer internal tools — multi-tenancy adds cost you would not recover
- Ideas with no first paying customer identified; the tenancy model needs a real user
- Teams wanting a SaaS shell with no thinking about pricing or plan boundaries
What usually goes wrong
Isolation enforced in application code
One missing `where tenant_id = …` is a data breach. Relying on every developer remembering it on every query is a policy, not a guarantee.
Plans are a marketing page, not a system
If limits and feature gates are not enforced in code, upgrades never get triggered and the pricing page becomes fiction.
Onboarding needs you in the room
If a new tenant cannot be provisioned, seeded and running without manual work, growth is capped by your calendar.
The app dies without internet
In many MENA settings — classrooms, warehouses, clinics — connectivity is intermittent. A cloud-only client is unusable exactly when the work happens.
What Makhloof Studio actually delivers
Isolation at the database
Postgres Row-Level Security with tenant scoping, so a forgotten filter returns nothing instead of returning someone else's data. The guarantee holds even when the application code is wrong.
Subscriptions and plan gating
Plans, seats, usage limits and feature flags enforced server-side, with trial, upgrade, downgrade and dunning paths that behave sensibly at the boundaries.
Self-serve tenant provisioning
Sign-up creates a fully seeded workspace — roles, defaults, sample data and invitations — with no manual step from you. Qooty's partner portal works exactly this way.
Offline-first clients where it matters
Local-first data with conflict-aware sync, so the product keeps working on a bad connection and reconciles when it returns — the architecture behind Mudarris running a whole tutoring business on-device.
Shipped, not theorised
Every claim on this page maps to a case study you can read in full.
Typical modules
A realistic scope for this kind of build. Yours will be a subset — the first call is where we cut it down.
Tenancy & access
- Row-Level Security tenant isolation
- Workspace provisioning and seeding
- Roles, permissions and invitations
- SSO-ready authentication
- Per-tenant configuration and branding
- Data export and account deletion
Billing & plans
- Plan, seat and usage limits
- Trials, upgrades and downgrades
- Server-enforced feature gating
- Invoices and payment retries
- Regional payment gateways
- Revenue and churn reporting
Product surfaces
- Web application (Next.js)
- Cross-platform mobile app (Flutter)
- Offline-first sync where needed
- Admin console for your own team
- In-app notifications and email
- Usage analytics per tenant
How this gets built
- 01
Define a tenant
Is it a company, a branch, or a user? Everything downstream — billing, permissions, data model — follows from this one decision, so it is made deliberately.
- 02
Isolate before you build features
Tenancy and access control land first. Retrofitting isolation into a live product with real customer data is the most expensive rewrite in SaaS.
- 03
Ship a paid-ready MVP
The first release includes billing and plan gating, not just the core workflow. A SaaS that cannot charge is a demo.
- 04
Instrument, then iterate
Per-tenant usage analytics from day one, so the next features are chosen from evidence instead of the loudest customer.
Typical stack
Worth knowing before you write.
A short, honest filter. It saves both of us a call that was never going to work.
A good fit if
- You have a real business or a funded idea, and a decision-maker in the room
- The product has to handle money, roles, or operations correctly — not just look good
- You want one senior engineer accountable end to end, not a rotating team
- Arabic and English both matter to your market
- You can give a few hours a week to reviews and decisions
Not a fit if
- You need a team of ten starting Monday — that is an agency's job, not mine
- The budget is fixed before the scope exists and cannot move
- You are looking for the cheapest possible quote rather than the right build
- Nobody on your side can answer product questions within a few days
- You want equity-only work or an unpaid prototype
What you get in the first call
Fifteen minutes, free, no deck.- A straight answer on whether this is buildable the way you imagine it
- The two or three decisions that will drive most of your cost
- A rough shape: phases, surfaces, and where the risk sits
- An honest ballpark range — or a referral if I am not the right fit
What to prepare
None of it has to be polished.- One sentence on what the business does today
- The workflow that hurts most, described in plain language
- Who needs to log in, and what each of them does
- Any deadline that is real, and why it is real
- A budget range you are comfortable discussing openly
Answered straight
- Why Row-Level Security instead of separate databases?
- Separate databases per tenant are simple to explain and painful to operate — migrations, backups and cross-tenant reporting all multiply. Row-Level Security gives you a database-enforced guarantee with one schema to maintain. Where a customer genuinely requires physical separation, that is a per-tenant decision rather than the default.
- Can you productise our existing internal tool?
- Often yes, and it is one of the strongest starting points — the workflow is already validated by your own operations. The work is usually tenancy, billing, onboarding and hardening rather than rebuilding the core.
- Do we need an offline-first mobile app?
- Only if your users work where connectivity fails — classrooms, warehouses, field sites. It is a meaningful cost, so it should be a deliberate answer to a real constraint. Mudarris needed it; most SaaS products do not.
- How fast can a first version ship?
- A focused, paid-ready MVP — one core workflow, tenancy, billing and an admin console — is a multi-week engagement when the scope is genuinely held. Scope discipline, not speed of typing, is what makes that possible.
- Who owns the infrastructure?
- You do. Everything runs in your accounts — database, hosting, payment provider — and the deployment pipeline is handed over with the code.
Written for buyers, not for engineers.
Need a SaaS platform like this?
Tell me who your first paying tenant is and what they do every day. That is enough to shape a first release.