How I work with you
SaaS platform development
SaaS platform development is building software that serves many customers from one deployment: every tenant isolated in its data, configuration, branding, and domain, while there is still one system to run and one codebase to change. The decisions that decide whether that holds — how tenancy is modelled, how identity works, how money moves — are settled before any feature is built, because they are the expensive ones to reverse. I have made those decisions three times on my own products, and I still operate one of them: Makook, a multi-tenant commerce platform for merchants in the Syrian market.
Multi-tenant SaaS platforms where tenancy, identity, and money are settled before the first feature — because those are the decisions you cannot reverse.
Who needs a multi-tenant SaaS platform?
You need a SaaS platform when the same software has to serve many customers at once and each of them expects it to be theirs — their data, their configuration, their branding, their domain — while you still want one system to deploy and one codebase to change. That is a structurally different product from software built for a single company, and the difference is decided in the first month rather than discovered in the second year.
In practice that is one of three situations:
- You are building a product from scratch that will be sold to many businesses, and you want the decisions underneath it made once, properly.
- You built something for one customer, it worked, and now other businesses want it — which is the point at which multi-tenancy stops being a feature request and becomes a rebuild.
- You have a platform in production and the parts that hurt are the ones underneath the features: tenant isolation, identity, plan limits, billing, or a per-tenant cost that grows faster than the revenue per tenant.
I work with founders, technical co-founders, and operations leads at startups and SMEs, mostly across the Gulf and the wider MENA region, in Arabic and English.
What does building a SaaS platform include?
Building a SaaS platform covers the full lifecycle rather than the build phase alone: business analysis and product planning, architecture and system design, development and delivery, cloud deployment and scaling, and App Store releases where the product has a mobile surface. On a SaaS platform specifically, the work is:
- The tenancy model — what is isolated, what is shared, and what each tenant costs you. Decided against your commercial model, not in the abstract.
- Identity and access — who a user is, which tenants they belong to, and what they may do inside each one.
- Plans, limits, and billing mechanics — what a plan actually restricts and where that is enforced, so a limit is a property of the system rather than a line in the sales deck.
- Module boundaries — catalogue, orders, payments, notifications, reporting, separated properly, so the parts that change weekly are not welded to the parts that change once a year.
- Tenant configuration and theming to the depth your market needs and no further, with the configuration-versus-bespoke line drawn explicitly.
- Integrations with the providers your market actually uses — payment rails, delivery partners, messaging — each behind one interface, so a tenant sees one order state rather than five vendor-shaped ones.
- Deployment, environments, and observability, sized so you can answer “which tenant, which query, which provider” before it becomes an incident.
- The operational tooling you need in week one — tenant provisioning, support access, and the ability to correct data without a database client.
How does a SaaS platform build run?
A SaaS platform build starts with the model, not the screens. Tenancy, identity, and money are settled and written down with you before any interface exists, because those three answers decide what the rest of the build costs.
From there the lifecycle runs in the order it has to:
- Business analysis and product planning — what the product is, who the tenant is, what a plan means commercially, and which constraints are already fixed.
- Architecture and system design — the tenancy model, the module boundaries, the integration boundaries, and each decision that would be expensive to reverse, recorded with the reasoning behind it.
- Development and delivery — built as a modular monolith by default: real boundaries, one deployable unit, seams left in place.
- Cloud deployment and scaling — environments, provisioning, and the traces that make a slow request answerable rather than debatable.
- App Store releases where there is a mobile surface.
The same person owns all five. That is the point of the model rather than a limit of it: the person choosing the tenancy model is the person who has to live with it. On Makook I still do — I founded that platform, architected it, and operate it today, incidents and migrations included. That is what “I understand both the technical system and the business it has to serve” means on this page, and it is the version of the claim you can go and check.
I also train teams on this material: I have given talks on Multi-Tenancy Architecture and How to Scale a SaaS Platform, both at Arabic Dev Group Malaysia, and run multi-day practical courses on architecture for engineering teams — including for government bodies in the Gulf.
Where I've done this
Makook
OngoingA Syrian market e-commerce platform — an independent store for every merchant, with local payments and delivery built into the core. Founded, built, and still running it.
eMenu
Digital menus for restaurants and hospitality in the Saudi market — a multi-tenant platform where the menu is a live system, not a PDF behind a QR code.
Tajer
E-commerce for Arab businesses worldwide — a store platform built for merchants whose customers, currencies, and shipping routes cross borders.
B2B flight booking platform
A B2B flight ticketing system for travel agencies — search, book, issue, and reconcile against supplier inventory, with agency credit and margin handled as core mechanics.
Questions about this work
What has to be decided before the first feature of a SaaS platform?
Three things: tenancy, identity, and money. What is isolated per tenant and what is shared; who a user is and which tenants they belong to; and how plans, limits, and payment actually work. Every feature you build afterwards is either straightforward or impossible depending on those answers, and all three are expensive to change once real customers hold data in the system. On Makook they were settled before any feature existed, which is the same order I work in for clients.
Should each customer get their own database, or share one?
That is a commercial decision wearing technical clothes, and the honest answer comes from your pricing model rather than from a best practice. Per-tenant infrastructure gives you the strongest isolation and the simplest story for a customer who demands it, and it makes your cost scale with your customer count. Shared infrastructure with careful query discipline keeps per-tenant cost near zero and puts the burden on getting isolation right in the code. Makook has a permanently free plan that takes no commission, which rules out any design whose cost grows with tenants — so the architecture followed the commercial model, not the other way round.
Can I launch for one customer now and add multi-tenancy later?
You can, and it is usually the most expensive path available. Multi-tenancy is not a layer you add on top of a working single-customer system; it reaches into the data model, identity, every query, every background job, and every integration. The same is true of bilingual structure and multi-currency handling. These are cheap to design in and painful to retrofit, which is why I treat them as architecture questions at the start rather than roadmap items.
How much can tenants customize before it stops being one product?
The line to hold is between configuration and a bespoke deployment per customer. Real theming, layout control, and imagery can be tenant-level configuration served by one codebase — that was the central design problem on eMenu, where a restaurant's menu is part of its identity and every tenant has to look distinct. Once a customer's requirement can only be met by code that runs for that customer alone, you have started maintaining several products with one team. Deciding where that line sits is a product decision, and it is better made deliberately at the start than discovered later.
Do I need microservices to build a SaaS platform?
Not on day one, and usually not for a long time after. My default is a modular monolith: real boundaries between modules, no shared tables across them, one thing to deploy. A platform has a lot of surface area but rarely needs independently scaled services early, so this gives you the discipline of separation without the operational cost of a distributed system — and the seams stay in place, so a module can move out later if load ever justifies it. Microservices bought before you need them are a running cost paid in deployment complexity and debugging time.
Does supporting Arabic change the architecture, or just the styling?
The architecture. Content, prices, and business rules have to be locale- and market-aware at the storage layer rather than translated at render time, and right-to-left layout with correct Arabic typography is a structural requirement, not a stylesheet. I learned this building Tajer as an Arabic-first platform rather than a translated skin over an English one, and it is why I now treat bilingual structure as a design decision made at the start.
SaaS platform development — tell me what you're working with.
Start a conversation