On this page
Why the SaaS model earns its complexity
Building software once and selling it many times is a better business than building it once and selling it once. That is the entire argument, and it is a strong one. But the model asks something in return: every customer now shares your infrastructure, your release schedule and your incidents. A bug you ship at nine in the morning is a bug every customer has by nine-oh-five. The engineering discipline SaaS demands is the price of the economics. When the trade is worth making, the advantages to your business are concrete:
- Predictable revenue. Subscriptions turn lumpy project income into a base you can plan and hire against.
- One codebase to maintain. Rather than twelve slightly different customer installations, each drifting further from the others every quarter.
- Improvements compound. A feature built for one customer becomes an asset every customer gets, and a reason for the next prospect to sign.
- You can see what happens. With one hosted system you know which features get used and where users stall — which is not true of on-premise software.
- Faster sales cycles. No procurement conversation about servers, and a trial that starts in minutes rather than after an installation project.
The counterweight is that you carry the operational burden your customers used to carry. Uptime, backups, security patching and capacity planning are now your problem, priced into a monthly fee. If you have not budgeted for that, you have not budgeted for SaaS. What follows is largely about keeping that burden proportionate as you grow — whether you are building a multi-tenant platform from scratch or turning an existing custom application into a product.
Choosing a multi-tenancy model
This is the decision teams agonise over most and, honestly, the one where the default answer is right more often than the debate suggests. You have three broad options for keeping one customer's data separate from another's, on a spectrum from cheap-and-shared to expensive-and-isolated.
Shared schema means every tenant's rows live in the same tables, distinguished by a tenant identifier column. One database, one set of migrations, one connection pool. It is the cheapest to run and the fastest to change, and its weakness is exactly what it sounds like: a single missing WHERE tenant_id = ? is a data breach. That risk is managed with framework-level enforcement — row-level security, or query filters applied globally rather than remembered by each developer — not with code review discipline.
Schema-per-tenant gives each customer their own schema inside a shared database. Separation is clearer and per-tenant backup and restore becomes straightforward. The cost arrives at migration time: a schema change is now a job that runs hundreds of times, and it will partially fail eventually. You need tooling for that from day one, not from the day it breaks.
Database-per-tenant is the strongest isolation short of separate infrastructure. Noisy neighbours disappear, a tenant can be pinned to a region, and enterprise security questionnaires get easy answers. It is also the most expensive per customer and the heaviest to operate — unsuitable for a low-priced self-service tier, entirely reasonable for a handful of large contracts.
| Dimension | Shared schema | Schema-per-tenant | Database-per-tenant |
|---|---|---|---|
| Infrastructure cost per tenant | Lowest | Moderate | Highest |
| Blast radius of a query bug | All tenants | One tenant | One tenant |
| Schema migrations | One run | N runs, needs orchestration | N runs, needs orchestration |
| Per-tenant backup / restore | Awkward | Straightforward | Trivial |
| Noisy neighbour risk | High | Moderate | Low |
| Per-tenant data residency | Not practical | Limited | Natural fit |
| Best suited to | Self-service, many small tenants | Mid-market, moderate tenant counts | Regulated or large enterprise accounts |
The choice is not permanent, but the direction matters. Moving from shared schema to isolated databases is a migration you can plan and execute per tenant. Going the other way — consolidating hundreds of drifted databases back into one — is an archaeology project. Start shared unless you have a named reason not to, and thread the tenant identifier through every layer so you keep the option to split later.
Security and tenant isolation
Tenant isolation is not a database feature. It is a property of the whole request path, and it fails at the seams. The database might be perfectly partitioned while the cache key omits the tenant, or a background job inherits the wrong context, or the storage bucket is organised by upload date rather than by tenant. Every one of those is a real class of bug, and none of them show up in a schema diagram.
The practical rule is that isolation should be enforced somewhere a developer cannot forget it. Resolve the tenant once, at the edge of the request, from the authenticated session rather than from anything the client sends. Push it into the data access layer so an unfiltered query is impossible rather than merely discouraged. Include it in every cache key, queue message and storage path. Then test it adversarially: authenticate as tenant A, request tenant B's identifiers, and assert on a not-found rather than an empty list — an empty list tells an attacker the record exists.
Beyond isolation, the security work that matters is unglamorous: an audit log of who did what to which tenant's data, role-based permissions customers administer themselves, encryption in transit and at rest, and a real answer to what happens when a customer leaves and wants their data deleted. Enterprise buyers in Dubai and Riyadh ask all of these in procurement, so having the answers ready shortens sales cycles.
Billing and subscriptions
Billing looks like a solved problem until you build it. The mechanics — cards, invoices, retries, tax, refunds — should come from an established provider, and in the Gulf you will want one that handles regional payment methods and can produce compliant tax invoices. If your customers include Saudi entities issuing tax invoices, the requirements are stricter than a generic subscription flow allows; that is ground we cover in our ZATCA e-invoicing work.
What you should own yourself is entitlements: the mapping from a plan to what the tenant is allowed to do. Keep that logic in your own code, as explicit limits and feature flags per tenant, and let the billing provider tell you which plan is active. Teams that scatter plan names through conditionals across the codebase discover the cost the first time sales invents a custom package for one important customer.
Two details repeatedly cause pain. Usage metering: if you bill on anything other than seats, the meter must be accurate, idempotent and reconcilable, because customers will dispute it and you need to show your working. And mid-cycle plan changes: proration, downgrades that breach current usage, and trials that convert are where the edge cases live. Decide the policy with your commercial team before you write the code, not after a customer complains.
Onboarding and time-to-value
The most expensive gap in most SaaS products sits between signup and the first moment the customer sees something useful. Nobody adopts a platform for its feature list; they adopt it because they got a result in the first session. If your product needs a week of configuration before it does anything, you have not built SaaS — you have built enterprise software with a credit card form attached.
Getting this right is mostly engineering, not copywriting. It means import tooling that handles the messy spreadsheet your customer actually has rather than the clean template you wish they had, with a preview step and clear errors. Defaults sensible enough that an empty tenant is still functional. A demo tenant with realistic data so an evaluator can click around before committing. And interface design that respects someone evaluating you between meetings.
It also means instrumenting the funnel so you know where people stop. If a large share of trials never complete data import, that is not a marketing problem, and no amount of new features will fix it. The same discipline decides whether consumer products succeed — the food delivery apps and marketplaces we have built live or die on first-session completion — and it transfers directly to B2B software.
Data residency in the Gulf
If you are selling to enterprise or government customers in the UAE and Saudi Arabia, expect the question of where data physically lives to come up early. Both countries have data protection regimes, and some sectors carry stricter expectations than the general baseline. The rules are not static, so the only responsible position is that residency requirements are confirmed against current regulation for your sector and your customers, per engagement, rather than assumed.
Architecturally, what we can say is this. Both AWS and Microsoft Azure operate regions in the UAE and Saudi Arabia, so in-region hosting is available. The question is whether your architecture can use it. Pinning a tenant to a region is straightforward if tenants map to databases and your routing layer knows where each one lives; it is close to impossible if every tenant's rows are interleaved in one shared table in one region. This is the most common reason we see teams pushed toward database-per-tenant for part of their customer base — not performance, but geography. And note that residency is frequently a commercial requirement before it is a legal one: procurement teams ask regardless.
Observability and support
In a multi-tenant system, "the app is slow" is not a useful signal. You need to know it is slow for one tenant, and preferably which query is causing it. That means tagging metrics, logs and traces with the tenant identifier from the first day, so when a customer calls you can filter to their traffic in seconds rather than reconstructing events from aggregate dashboards.
Set service level objectives on what customers actually feel — page load for the main workflow, time to complete a critical action, background job lag — rather than on CPU utilisation, and alert on those. Build support tooling early too: a safe, audited way for your team to view a tenant's state without direct database access, because otherwise engineers end up running ad-hoc SQL against production at midnight, which is how the worst incidents start. The same instrumentation feeds product decisions, which is where data analytics and business intelligence stop being a separate project and become a by-product of doing operations properly.
What it actually costs to scale
Cloud costs for a SaaS product rarely scale the way founders expect. The compute serving requests is often not the biggest line. What grows faster is storage nobody deletes, data transfer between availability zones, managed service minimums paid per environment rather than per customer, and the observability stack itself — log ingestion has an unpleasant habit of becoming a top-three bill.
The metric worth tracking early is cost per tenant, broken down by component. Without it you cannot tell whether your pricing works, and you will not notice that your largest customers consume most of your infrastructure while paying the same as everyone else. In our experience the first serious optimisation almost always comes from data lifecycle policy — archiving or deleting what nobody reads — rather than from clever compute changes.
Be equally honest about the human cost. On-call rotation, security patching, support and compliance questionnaires are recurring expenses that scale with customer count and never appear on a cloud bill. A SaaS business plan that models only infrastructure is modelling the smaller half.
How Inovsion helps
We are a software engineering firm working across the UAE, Saudi Arabia and India. On SaaS work, what we bring is judgement about which of the decisions above you need to make now and which you can defer — because the fastest way to burn a budget is to build for scale you do not have.
- Architecture that keeps options open. We usually recommend shared schema with the tenant identifier enforced at the data layer, structured so that lifting one tenant into their own database — for an enterprise contract or a residency requirement — is a planned migration rather than a rewrite.
- The unglamorous platform layer. Tenant management, roles and permissions, audit logging, entitlements, admin tooling and the deployment pipeline. This is the half of a SaaS product that gets under-budgeted, and the half that determines whether you can support customers once you have them.
- Regional reality, not theory. We have built and integrated a ZATCA e-invoicing solution covering EGS onboarding across a range of ERP platforms, and we work with clients in Saudi Arabia. Gulf tax, Arabic and residency requirements get handled in the design, not as a late surprise.
- Products that have shipped. Our portfolio includes real platform work — ClueMaster, IoT-enabled software managing escape rooms across multiple locations; Rising Walls, a property portal; OneTuch, a logistics and transportation platform. Different domains, the same underlying problems.
- Adjacent capability when you need it. Mobile clients via Flutter, Android and iOS; machine learning where it genuinely helps; ERP and CRM integration when your SaaS has to live alongside systems your customers already run.
We will also tell you when the answer is not a new SaaS product. Sometimes the right move is extending what you have, or buying off the shelf, and we would rather say so early than take a year of your budget proving it.
Frequently asked questions
Should we start with shared schema or database-per-tenant?
For most new products, shared schema with a tenant identifier on every row is the sensible default. It is the cheapest to run, the simplest to migrate and the fastest to build. The exception is when you already know your first customers are large regulated enterprises who will demand physical separation in contract negotiations, or when you have a hard data residency requirement that forces some tenants into a specific country. In those cases, design for a mixed model early — shared schema for the long tail, dedicated databases for the few who pay for it — because retrofitting that split later is painful.
How much does it cost to build a SaaS MVP?
It depends almost entirely on scope, and any firm quoting a number before understanding your workflows is guessing. What we can say is where the money goes. In our experience the visible product — the screens users see — is often less than half the effort. The rest is authentication, tenant management, billing, admin tooling, audit logging and the deployment pipeline. Teams that budget only for the visible half run out of money at roughly the point the product becomes sellable. Talk to us about your specific scope and we will break the estimate down by component rather than give you a headline figure.
Can we build our own subscription billing instead of using a provider?
You can, and you will probably regret it. Proration, mid-cycle plan changes, failed payment retries, tax handling, credit notes, refunds and dunning are individually simple and collectively a product in their own right. Use an established billing provider for the mechanics. What you should own is the mapping between your plans and your feature entitlements, because that logic is specific to your product and you will change it often. Keep entitlement decisions in your own code and let the provider handle money movement.
Does our SaaS data have to stay in the UAE or Saudi Arabia?
It depends on your sector and your customers, and the honest answer is that this must be confirmed against current regulation for your specific case rather than assumed from a blog post. Both the UAE and Saudi Arabia have data protection regimes, and some sectors — government, healthcare, financial services — carry stricter expectations than others. Separately from regulation, in-region hosting is frequently a commercial requirement: enterprise buyers in the Gulf ask about it in procurement whether or not the law compels it. Both major cloud providers operate regions in the UAE and Saudi Arabia, so the architectural question is usually whether your design can pin a tenant to a region at all.
When should we move from a single application to microservices?
Later than most teams think. A well-structured single deployable will carry a SaaS product a long way, and it is far easier to debug, test and deploy. The signals that genuinely justify splitting something out are organisational — multiple teams blocking each other on releases — or a component with a genuinely different scaling or isolation profile, such as a heavy reporting engine or a background processing pipeline. Splitting a system because the architecture diagram looks better tends to buy you distributed transactions and network failures in exchange for nothing.
What is the most common reason SaaS products fail after launch?
In our experience it is onboarding, not architecture. Products that lose customers usually lose them in the first two weeks, before anyone has stressed the database. A prospect signs up, cannot get their data in, cannot see anything useful without configuration work nobody explained, and quietly stops logging in. The engineering effort spent making the self-service path work — import tools, sensible defaults, a populated demo tenant — usually returns more than the same effort spent on features.
Planning a SaaS product?
Tell us what you are trying to sell and who to. We will give you a straight read on architecture, scope and the parts of the build that people usually forget to budget for.