What drives the cost of a SaaS build, and should we start with a smaller first version?

The tenancy model and the billing, more than the feature list. A product that has to hold companies rather than users, invoice them properly and meter what they use has a data model underneath it that a feature count does not show, and that is where the engineering sits. Start smaller, yes, but not by deferring those three: a first version with one workflow and a correct tenant model grows easily, and a first version with five workflows and a single-tenant shortcut is a rebuild wearing a launch date.

We bill customers here. What does the e-invoicing programme mean for our product?

For a software vendor the invoice is something your product emits, so a change to the invoice format is a change to your roadmap rather than to your finance team’s routine. The obligation is being phased in by revenue band on published dates, and it moves the invoice from a document you generate to structured data you exchange, which is a schema question for anyone whose billing is part of the product. Because your tenants sit in different revenue bands, they reach their own dates at different times, so the product needs to support both shapes for a period. The dated timetable is set out on the workflow automation page.

Do we have to hold our customers’ data in the UAE?

Not as a blanket rule, and you will be asked the question in almost every enterprise sale regardless. The answer that works is a specific one, per tenant, rather than a paragraph in a policy: which region their data is in, who can reach it, and what happens if they ask for it back. There are local regions available if a customer’s own obligations require one. Which regime a given tenant is answering to follows their registration rather than yours, and that distinction is set out on the CRM page.

One customer wants to use it under two of their companies. How does that work?

As two tenants under one relationship, if the product was designed for it, and as a support problem if it was not. Groups here commonly run a mainland company and one or more free zone entities, each with its own trade licence and its own registration, and each needs its own invoice even when one person is buying for both. The workable model separates the billing entity from the account and lets one relationship hold several, which is a schema decision made once. Bolting it on later means splitting live tenants, which is the migration everyone postpones.

Can we charge in AED and in another currency from the same product?

Yes, and it is a decision to make at the schema rather than at the pricing page. Prices, invoices, taxes and reporting all have to know which currency a given tenant is on, and a product that stored a single number for a plan will need every one of those revisited. Set it up as a per-tenant property at the start and adding a second currency later is a configuration; leave it and it is a migration. The same applies to the tax treatment, which differs by where the buyer is rather than by where you are.

Do we need a mobile app at all, or is the web product enough?

Often the web is enough, and we will say so. A companion earns its place when something has to arrive rather than wait, when the work happens away from a desk, or when one focused view is opened many times a day. It does not earn its place by mirroring the browser, which produces a second product to maintain and the first one to fall behind. Whether a product needs an app at all is argued in full here, and it is worth reading before commissioning one. If it does earn its place, how one gets built here is the mobile pillar’s subject, and the handsets and languages your first tenants will actually be on are set out for Dubai.

Who owns the code and the billing accounts at the end?

You do, and the billing accounts matter more than people expect. The repository and the hosting are the obvious ones; the gateway, the subscription platform and the cloud account are the ones that quietly end up in a supplier’s name, and those are where your revenue actually flows. We open them under your entity at the start rather than transferring them at the end, because a transfer of a live billing account is an outage with an invoice run attached.

SaaS app development · UAE

SaaS apps that invoice UAE companies correctly.

SaaS app development here means invoicing a company with a trade licence and a tax number. That has to be in the data model, because adding it later is expensive.

Scope the tenancy and the billing

What SaaS app development is

What SaaS app development involves here.

Three decisions sit under a subscription product, and all three are data-model decisions. None of them is visible in a demo, and each one is expensive to revisit once tenants are live.

Each customer is a company.

A customer here is a company with a trade licence, not a person with a login. A group that runs a mainland company and a free zone entity is two buyers, and a product that models one company per account discovers that at the first renewal.

Invoices your buyers accept.

A business buyer needs a tax invoice, with their own registration on it and VAT shown at 5%. A product that stores an email address cannot produce one, and retrofitting the fields into a live billing schema is a migration rather than a sprint.

Where their data sits.

Every serious UAE buyer eventually asks where their data is held. The product needs an answer that is true per tenant, not a paragraph, and there are local regions to give it in.

The scope

Six layers under a subscription product.

Six layers, and a demo shows one of them. The other five are what decide whether the tenth customer costs the same to onboard as the first.

Customers kept apart in the data.

Isolation written into the queries rather than into a filter somebody remembers to apply

Output

a boundary a security review can be shown, instead of one a developer promises

IsolationEnforced

Subscriptions and a proper tax invoice.

Plans in AED, a renewal that runs itself, and an invoice carrying the buyer’s registration with VAT shown at 5%

Output

something a customer’s finance team can file without writing to you

AED plansTax invoice

Usage metered, limits that hold.

What each tenant consumed, counted where it happens rather than estimated monthly, with the limit enforced in the product

Output

a plan structure you can change without a spreadsheet

MeteringLimits

Sign-in your customers manage themselves.

Their own people, their own roles, and their own identity provider where they have one

Output

an account a customer’s IT can run without raising a ticket with you

Single sign-onRoles

A console for your own team.

Every tenant, their plan, their usage and their invoices in one operator view

Output

support answered from a screen rather than from the database

TenantsOperator view

An interface others can build on.

A documented interface and webhooks, so a customer’s own systems can read and be told rather than being exported to

Output

the integration request answered by documentation

APIWebhooks

Multi-tenant, or a build you replace

Two architectures that look identical in a demo.

Both demonstrate the same product to the same buyer. They diverge at the tenth customer, and again the first time a rule changes.

	A single-tenant buildOne customer at a time, copied	Multi-tenant from the startOne product, many companies
Onboarding a customer	A deployment, and a version number that drifts from the last one.	A record. The tenth customer costs what the first one did.
Keeping them apart	Separate copies, which is genuinely safe and genuinely unmaintainable.	Enforced in the data layer, and demonstrable to a security review.
The tax invoice	Raised by hand each month, from a spreadsheet somebody owns.	Issued by the product, with the buyer’s registration and VAT on it.
A group, two licences	Two deployments, and a support ticket about which one has the data.	Two tenants under one relationship, billed separately, reported together.
When a rule changes	The same change made once per customer, and missed on at least one.	One change, released once, and it is true for everybody that afternoon.

When single-tenant is right.

When you have one customer and a genuine reason to believe you will not have five, which is rarer than it sounds and is usually a services engagement wearing a product name. Everything else is multi-tenant from the first line, because the retrofit is a migration with live customers on it. Whether the product needs a mobile app at all is a question before this one, and where the back office rather than the product is the real problem, that is a different engagement.

What we find on subscription products here

Why your customer is a company.

Webzenia has worked with Gulf clients since 2018. Four things about selling software by subscription to UAE businesses, and none of them is a feature.

01of 04
A tenant is a licenceNot a login
Groups here buy through one company and use another.
A mainland company and a free zone entity are separate buyers with separate registrations, and a product modelling one company per account cannot invoice them properly. A Business Bay proptech on a mainland DET licence selling to brokerages meets this at the first group renewal.
Our methodThe tenant model settled against real customer entities before the schema.
02of 04
The invoice is the outputNot the paperwork
Your product issues the tax invoice, not your finance team.
It has to carry the buyer’s registration and show VAT at 5%, and the format is moving from a document to structured data on a phased, published timetable. A vendor whose customers span revenue bands has tenants reaching that point on different dates.
Our methodInvoice fields designed against the published specification, not a template.
03of 04
They will ask where it sitsAnd a paragraph is not an answer
UAE buyers ask where their data is held.
A DIFC-registered fintech selling to regulated customers is asked this in every procurement cycle, and the answer has to be true per tenant rather than in general. There are local regions to give it in, and the regime a tenant sits under follows their registration rather than yours.
Our methodThe hosting answer written down per tenant, before the first enterprise sale.
04of 04
The product arrived tooAnd it bills like somewhere else
Foreign products cannot invoice a UAE company properly.
A Fujairah port-services software vendor buying from an overseas platform will ask for an AED invoice with its own registration on it, and often cannot get one. The gap is a schema, not a setting, which is why it is quoted as a project by the vendor and read as obstruction by the buyer.
Our methodCurrency, registration and tax fields modelled once, never bolted on per market.

What the engagement covers

Inside a subscription build.

Six stages, and the first one is a schema decision. Everything expensive about a subscription product is decided before the first screen is drawn.

The customer model and your plans.

Who a tenant is, how a group with more than one licence is held, what a plan contains and what happens at the limit. These four answers are the schema, and they are the expensive ones to change.

Tenancy
Plans

The product and the console together.

The customer-facing product and the operator console are built as one system, because a product your own team cannot administer becomes support answered from the database.

Product
Console

Billing, metering and the tax invoice.

Subscriptions and usage wired to a gateway that settles where you bank, and an invoice that carries the buyer’s registration and shows VAT at 5% without anyone editing it.

Metering
Tax invoice

Keeping each customer’s data separate.

Isolation tested by trying to break it with a second tenant rather than by reading the code, and the product then run under the volume the plans imply rather than the volume it has today.

Isolation
Load

A customer who signs up alone.

Self-serve onboarding, the first invoice issued automatically and the reporting already running, so the launch is a customer arriving rather than an announcement being made.

Self-serve
First invoice

Handover, billing accounts included.

Code, documentation and the gateway, hosting and billing accounts in your own name. A product whose revenue flows through somebody else’s account is a product with a hostage in it.

Documented
Your accounts

Our stack

The tools behind a subscription product.

The boundary, the money, the answer about where it sits, the second surface, and the screens nobody designs. Select one to see what it settles.

PostgreSQL

Why PostgreSQL

Tenant isolation is a database question before it is an application one, and row-level security puts the boundary where a query cannot forget it rather than where a developer has to remember it.

How we excel

We enforce the tenant boundary in the database rather than in a filter, so the worst case of a missed condition in application code is an empty result rather than another company’s data.

Boundary enforcedDemonstrable to a reviewIsolation

Row-level securityIn the data

A filter in the codeBy habit

A database per tenantCostly

Trusting the ORMNo

How the build runs

From the data model to a paying customer.

The first fortnight produces a data model rather than a screen. Tenancy, plans and the invoice are the three decisions a live product cannot revisit without a migration.

01Weeks 1 to 2Scoped

Settling customers, plans and invoices.

We settle who a tenant is, how a group holding more than one licence is represented, what each plan contains and what happens when a limit is reached. In the same fortnight we establish what the invoice has to carry: the buyer’s registration, the currency, the tax line, and the format the obligation is moving toward. All four are schema decisions and all four are expensive later.

Tenantdefined as an entity
Plansand what happens at the limit
Invoicefields settled, not deferred

02Weeks 3 to 12Built

Building the product and the console.

The customer product and the operator console are built together, with the tenant boundary enforced in the data layer rather than in application code. Then it is tested by trying to reach one tenant’s data as another, which is a different exercise from reading the code and agreeing it looks right. Billing and metering go in with the invoice fields already decided.

Boundaryin the data layer
Isolationtested by attack, not review
Consolebuilt alongside the product

03Month 4 onwardRunning

The first customer who signs up alone.

Self-serve onboarding, an invoice issued automatically and the usage reporting already running, so the measure of go-live is a customer who arrived unattended rather than an announcement. After that the work is renewals and limits: the screens a customer opens in month eleven decide whether there is a month thirteen, and they are the ones nobody designs.

Onboardingself-serve, unattended
First invoiceissued by the product
Renewala designed screen, not an email

Settled in the first fortnight, so the tenant model is a decision rather than a discovery.

The schema, in writing

TenancyTax invoiceResidency

Our commitment

Our promises to a software vendor.

A subscription product fails at the tenth customer and at the first audit. These four are written into the scope because those are the two moments.

Customers kept apart, and we test it.
The boundary lives in the database, and it is proved by trying to reach one tenant’s records as another rather than by reading the code and agreeing it looks correct. A review can be shown the mechanism instead of a promise.
Invoices carry the buyer's tax number.
A business buyer needs a tax invoice with their own details and the VAT line on it. Designing that in costs a fortnight; adding it to a live billing schema with tenants on it is a migration nobody scheduled.
The billing and hosting accounts are yours.
The gateway, the cloud account and the subscription platform are yours from the first day, not transferred at the end. Revenue flowing through a supplier’s account is a dependency no contract makes comfortable.
We say when your web product is enough.
A companion that mirrors the browser is a second thing to maintain and the first to fall behind. Where nothing needs a phone we say so, and the case for building is here.

Common questions

SaaS apps, answered.

The tenancy model and the billing, more than the feature list. A product that has to hold companies rather than users, invoice them properly and meter what they use has a data model underneath it that a feature count does not show, and that is where the engineering sits. Start smaller, yes, but not by deferring those three: a first version with one workflow and a correct tenant model grows easily, and a first version with five workflows and a single-tenant shortcut is a rebuild wearing a launch date.
FAQ · 01
For a software vendor the invoice is something your product emits, so a change to the invoice format is a change to your roadmap rather than to your finance team’s routine. The obligation is being phased in by revenue band on published dates, and it moves the invoice from a document you generate to structured data you exchange, which is a schema question for anyone whose billing is part of the product. Because your tenants sit in different revenue bands, they reach their own dates at different times, so the product needs to support both shapes for a period. The dated timetable is set out on the workflow automation page.
FAQ · 02
Not as a blanket rule, and you will be asked the question in almost every enterprise sale regardless. The answer that works is a specific one, per tenant, rather than a paragraph in a policy: which region their data is in, who can reach it, and what happens if they ask for it back. There are local regions available if a customer’s own obligations require one. Which regime a given tenant is answering to follows their registration rather than yours, and that distinction is set out on the CRM page.
FAQ · 03
As two tenants under one relationship, if the product was designed for it, and as a support problem if it was not. Groups here commonly run a mainland company and one or more free zone entities, each with its own trade licence and its own registration, and each needs its own invoice even when one person is buying for both. The workable model separates the billing entity from the account and lets one relationship hold several, which is a schema decision made once. Bolting it on later means splitting live tenants, which is the migration everyone postpones.
FAQ · 04
Yes, and it is a decision to make at the schema rather than at the pricing page. Prices, invoices, taxes and reporting all have to know which currency a given tenant is on, and a product that stored a single number for a plan will need every one of those revisited. Set it up as a per-tenant property at the start and adding a second currency later is a configuration; leave it and it is a migration. The same applies to the tax treatment, which differs by where the buyer is rather than by where you are.
FAQ · 05
Often the web is enough, and we will say so. A companion earns its place when something has to arrive rather than wait, when the work happens away from a desk, or when one focused view is opened many times a day. It does not earn its place by mirroring the browser, which produces a second product to maintain and the first one to fall behind. Whether a product needs an app at all is argued in full here, and it is worth reading before commissioning one. If it does earn its place, how one gets built here is the mobile pillar’s subject, and the handsets and languages your first tenants will actually be on are set out for Dubai.
FAQ · 06
You do, and the billing accounts matter more than people expect. The repository and the hosting are the obvious ones; the gateway, the subscription platform and the cloud account are the ones that quietly end up in a supplier’s name, and those are where your revenue actually flows. We open them under your entity at the start rather than transferring them at the end, because a transfer of a live billing account is an outage with an invoice run attached.
FAQ · 07

Keep exploring

Explore Mobile App Development

Part ofMobile App Development

iOS App Development

Native Swift, and the entity Apple publishes as seller.

Android App Development

Kotlin, and the five manufacturer skins this market runs.

Cross-Platform Apps

One codebase, and the parts written per platform.

Flutter Development

One widget tree, and an Arabic screen that mirrors itself.

React Native Development

For teams that already write React and have to hold it.

eCommerce App Development

A shopping app costed against the repeat order.

On-Demand App Development

Two-sided products where the fleet is the harder half.

Enterprise App Development

Internal apps for staff who are not at a desk.

App UI/UX Design

A component system engineering builds from, in both directions.

Next step

Get your SaaS app scoped.

Send us what the product does and who it bills. We will come back with the tenancy shape, the billing model and what each one costs to change later.

Tell us what you need.

What SaaS app development involves here.

Each customer is a company.

Invoices your buyers accept.

Where their data sits.

Six layers under a subscription product.

Customers kept apart in the data.

Subscriptions and a proper tax invoice.

Usage metered, limits that hold.

Sign-in your customers manage themselves.

A console for your own team.

An interface others can build on.

Two architectures that look identical in a demo.

Why your customer is a company.

Groups here buy through one company and use another.

Your product issues the tax invoice, not your finance team.

UAE buyers ask where their data is held.

Foreign products cannot invoice a UAE company properly.

Inside a subscription build.

The customer model and your plans.

The product and the console together.

Billing, metering and the tax invoice.

Keeping each customer’s data separate.

A customer who signs up alone.

Handover, billing accounts included.

The tools behind a subscription product.

From the data model to a paying customer.

Settling customers, plans and invoices.

Building the product and the console.

The first customer who signs up alone.

Our promises to a software vendor.

SaaS apps, answered.

Explore Mobile App Development

iOS App Development

Android App Development

Cross-Platform Apps

Flutter Development

React Native Development

eCommerce App Development

On-Demand App Development

Enterprise App Development

App UI/UX Design

Get your SaaS app scoped.