Our entity is in a free zone. Can we sell this to customers on the mainland?

Generally through a distributor, a mainland branch or a permit rather than directly, and in Dubai the permit route runs under Executive Council Resolution No. 11 of 2025. For a product company that is not a legal footnote, it is the addressable market, which means it belongs in the first conversation rather than the legal review: it decides who the first customers can be, and therefore what the first version has to do. Which entity closes a deal also decides the tax treatment of it, and that is set out on the CRM page. One correction worth carrying into any conversation about founding here: the exemption people mean is available to a qualifying free zone person on qualifying income, not to free zone companies as a class.

Can it bill in AED, and which gateway should it run on?

Yes, and the choice follows where your customers are rather than where you are. Network International, Telr and PayTabs are the names a UAE finance team recognises, and a card charged from somewhere unfamiliar can sit in an approvals queue long enough to stall a renewal. For customers outside the country a global processor is simply better, and running both is common rather than a failure of decisiveness. What matters more than the logo is that the product issues a document the buyer will accept without an email exchange, from the first invoice. What your own company then owes on it is a separate subject, set out on the Dubai page.

How long until we have something a first customer can pay for?

It depends on one thing, and it is not the number of screens. A version that serves one company can be quick; a version that can take a second customer without a rebuild takes longer, and that difference is the whole reason this market quotes the same word at two weeks and at twelve. Ask any estimate which of the two it is describing. Ours is scoped backwards from a named buyer, with the exclusions written down, and it says plainly which parts are deferred until we know what people use. Nobody can give you a duration honestly without first telling you what is in it.

Does our customers’ data have to sit in the UAE?

Not as a general rule, and you will still be asked in most enterprise conversations. The federal law reaches a controller or processor outside the country that processes the data of people inside it, so being hosted elsewhere does not put you outside it, and a customer licensed in DIFC or ADGM is answering to its own regime rather than the federal one. There are in-country options if a buyer’s obligations require one, and the specifics of what is available where are on the enterprise software page. Decide it before the build: migrating a live product for one contract is the expensive version of this answer.

We have an internal tool that works. Can it be turned into a product?

Often, and it is the strongest starting position there is, because the hardest question in a product build has already been answered by somebody using the thing daily. Three things will be missing, and they are the same three every time: separation, so customer B cannot see customer A; a way to bill, because you have never had to; and everything that quietly assumed one company’s habits, its terminology and its exceptions. That is a defined piece of work rather than a rewrite. What it is not is a weekend, which is what the demo makes it look like. And where the tool is only ever worth having for you, improving it in place is the pillar’s subject rather than this page’s.

When does multi-tenancy actually have to be built in?

From the first commit, unless you can honestly say there will never be a second customer. It is the one part of the architecture that cannot be added quietly later: doing it afterwards means moving live accounts and their data while people are working in them, which is a migration with customers on it rather than a piece of engineering. Built in at the start it costs days. Added at fifty customers it costs a quarter and a difficult set of conversations. The exception is real, though: a product genuinely made for one organisation and priced that way should be built for one.

Who owns the code, and what does that mean when we raise?

You do, and it matters more here than on most builds because an investor will look. The repository, the cloud account, the billing account and the domain go into your entity’s name at the start rather than being transferred at the end, so ending an engagement is a permissions change rather than a migration. The version that causes trouble in diligence is not usually a hostile supplier, it is a well-meaning one whose account the product happens to live in. Ask about it in writing before any product engagement, here or elsewhere.

SaaS development · UAE

SaaS products ready for your first paying customer.

SaaS development here is quoted at two weeks and at twelve. What differs is not speed, it is whether the thing being built can serve a second customer.

Tell us who has already said yes

What SaaS development is

What SaaS development decides first.

One codebase, many paying customers, none of them able to see another. That is the whole definition, and almost everything difficult about the build follows from the third clause.

Many customers, one codebase.

You ship once and everybody gets it, which is what makes the economics work. The cost of that is isolation: every query, every file and every report has to know which customer it belongs to, and there is no version of the product where that is optional.

The first version is a choice.

Asked how long a first version takes, this market answers two weeks and twelve. Neither number is wrong; they describe different products. The short one usually serves one customer, and the second customer is what turns it into a rebuild.

Billing is part of the product.

Subscriptions, plan changes, renewals and a document the buyer’s finance team accepts are features, not admin. Built in from the first invoice they cost a fortnight; retrofitted onto live customers they cost a migration and a difficult month.

What gets built

Six kinds of SaaS build.

Six briefs, and the difference between them is who the second customer is. Which one you are in decides what the first version has to contain.

A version somebody will pay for.

The smallest thing a named customer would put a card behind, built so the second customer is a signup rather than a project

Output

a product in use, and a written list of what was deliberately left out

Named buyerExcluded, in writing

B2B, sold to companies.

Teams, seats, roles and an invoice a finance department will accept, because the person using it and the person paying for it are rarely the same

Output

a product that survives its first procurement conversation

SeatsInvoiced

Built for one trade.

A product that knows one industry’s vocabulary, documents and sequence, which is the only durable advantage a small vendor has against a horizontal giant

Output

depth in one trade rather than breadth in none

One tradeDeep

Keeping customers apart.

The part that decides whether customer B can ever see customer A: enforced in the data rather than in the screens, and tested by trying to cross it

Output

a boundary you can demonstrate, not describe

EnforcedTested

White-label, and an API.

Your product inside somebody else’s brand, or reachable by their developers, which is a distribution decision with an engineering bill attached

Output

a second channel, priced honestly before it is promised

DistributionVersioned

An internal tool made sellable.

The most common origin story here, and the shortest route to a real one: something that already works for one company, opened to others

Output

the three things that were never built because there was only ever one customer

Already worksOpened up

Three shapes a first version takes

Assembled, built for one, or built for many.

All three get called an MVP and all three demo well. They differ on the day a second customer says yes.

	Assembled on no-codeWired together from tools you rent	Built for one customerA real build, with one company in mind	Built for manyA product from the first commit
Who it can serve	A handful, as long as nobody looks closely at the seams.	One, properly. That is genuinely a good outcome for some products.	Any number, because separating them was the first thing built.
The second customer	A second copy of everything, kept in step by somebody remembering.	A fork, or a rebuild. This is where the money goes.	A signup. Nothing is copied and nobody is asked.
How it bills	A payment link, and somebody raising documents by hand each month.	An invoice, agreed once, usually outside the product.	Inside the product, with plan changes and renewals as features.
Changing it later	Fast, until the tool you rent changes its terms or its price.	Straightforward for the one customer, painful for everyone after.	A release. Everybody gets it at once, which is the point.
When it is right	Testing whether anyone wants it at all, before spending on a build.	A product genuinely made for one organisation and priced that way.	When you can name the second customer, or expect to within a year.

Where we would start.

Assembled, more often than founders expect. If the question is still whether anyone wants this, no-code answers it in weeks for the price of a subscription, and a build answers the same question months later at many times the cost. We will say so, and lose the project. That stops the moment you can name the second customer: from then on the rented tools are the constraint, and separation between customers is the one thing genuinely brutal to retrofit. If the product turns out to want a phone rather than a browser, that is a different question.

The UAE context

What MVP means in this market.

Webzenia has worked with Gulf clients since 2018. Four things about building a product here, and the first is visible on the search results page.

01of 04
One word, two answersTwo weeks, or twelve
The same first version is quoted at two weeks and twelve.
None of them says what moves it, and the honest answer is not speed. The short version usually serves one customer, and the second customer turns it into a rebuild. A Dubai Silicon Oasis logistics-software founder on a Dtec free zone licence is choosing between those quotes without being told they describe different products.
Our methodThe estimate stated with its variables, and what is excluded written down.
02of 04
What the short quote skipsAnd one of the three is legal
A short quote usually leaves out billing and isolation.
A product founded in a free zone reaches mainland buyers through a distributor, a branch or a permit under Dubai’s Executive Council Resolution No. 11 of 2025, so the licence is the addressable market rather than a footnote. A Hub71 fintech on an Abu Dhabi free zone licence meets it at the first onshore contract.
Our methodThe three settled in the scope, with the entity question raised before the build.
03of 04
Which rail the buyer acceptsNot which one you can open
UAE finance teams recognise some payment rails, not others.
Network International, Telr and PayTabs are the names a local buyer expects, and a card charged from somewhere else can stall a renewal in an approvals queue. The reverse holds too: for customers outside the country a global processor is simply better. A Dubai Internet City software team selling both ways ends up running two.
Our methodThe rail chosen against where the customers are, not against where the vendor is.
04of 04
It usually already existsAnd it works for exactly one company
Most products here began as an internal tool.
That is a strong position and a specific piece of work: the three things never built are separation between customers, a way to bill, and anything that assumed one company’s habits. A SPARK founder in Sharjah productising a monitoring tool built for one factory floor is not starting from nothing.
Our methodThe existing tool read for what one customer let it get away with.

What the engagement covers

Inside a SaaS build.

Six stages, and the first one can end with a recommendation not to build. Everything after it is priced against what the first customer actually agreed to pay for.

The scope, and the exclusions.

The smallest version a named customer would pay for, with the exclusions in a column of equal weight beside it, so a later argument has a document rather than two memories

Output

a scope, and sometimes advice to assemble it instead

Named buyerExclusions

The version they can pay for.

Three steps and no more: self-serve signup, the one workflow done properly, and charging with a card on file

Output

something in use with a card behind it, because a product nobody can buy is a prototype however finished it looks

One workflowChargeable

Billing, plans and invoices.

Plans, upgrades and renewals running inside the product, and a tax document the buyer’s finance team will accept, on a rail chosen for where the customers are

Output

revenue that arrives without anybody raising a spreadsheet

PlansCompliant document

Separation between customers.

Enforced in the data layer rather than in the screens, then tested by signing in as one customer and querying another’s records, where the answer is zero rows

Output

a boundary that has been attacked rather than reviewed

In the dataAttacked

Seeing what customers use.

Usage per account, and the moment somebody quietly stops signing in, visible without an engineer running a query

Output

a roadmap argued from behaviour instead of from the loudest customer

UsageChurn signal

Hardening, and the handover.

The scaling and security work done where customers actually went, and deliberately not done on the corner nobody reached. Plus the repository, the infrastructure and the billing accounts in your own name

Output

a product an investor can diligence

On the used partsYours

Our stack

Built with Stripe and PostgreSQL.

Five choices, each with a trade stated rather than a benefit listed. Select one to see what it buys and what it charges you for it.

Stripe

Why Stripe

Subscription billing, plan changes and renewals are a product to build in their own right, and this is the one nobody should be rebuilding in 2026.

How we excel

We choose it against where your customers are, not where you are. For buyers outside the country it is straightforwardly better; for a UAE finance team a local rail clears approval faster, and plenty of products end up running both.

Suits customers abroadCleared by a local buyerBest for

Chosen per marketBoth

A global rail onlyOutside

A local rail onlyOnshore

A payment linkNeither

How the build runs

From a paying customer to a product.

The order is set by where the money is. Nothing is hardened before we know which parts customers actually reached.

01Weeks 1 to 2Scoped

Scoping the smallest paid version.

We work backwards from somebody who has said they would buy it, and write down what is deliberately excluded next to what is in. The licence question is asked here rather than in a later legal review, because who you are allowed to sell to shapes which customers the first version has to satisfy. This phase can end with a recommendation to assemble it on tools you rent instead, and sometimes does.

Buyernamed, not assumed
Excludedwritten down
Licenceasked before the build

02Weeks 3 to 12Built

Building one workflow, with billing.

Signup, the core job and billing, built with the separation between customers already in the data layer, because that is the only part that is genuinely brutal to add afterwards. The billing rail is chosen against where the customers are. What we do not do is harden or scale anything at this stage: nobody yet knows which parts will carry the load, and guessing is how a first version arrives late.

Isolationin from the first commit
Billinga feature, not admin
Scalingdeliberately deferred

03Month 4 onwardRunning

Hardening what customers reached.

Usage tells us where the product is being used and where it is being avoided, and that is what gets the scaling and the security work rather than whatever seemed important at the start. The isolation boundary is attacked rather than reviewed. Then the repository, the infrastructure and the billing account move into your entity’s name, which is what makes the product something you can raise on.

Hardenedwhere usage went
Boundaryattacked, not reviewed
Accountsin your entity’s name

What is in and what is excluded, written down together, so a later argument has a document.

The scope, in writing

Named buyerIsolation firstScaling deferred

Our commitment

Four promises about the build.

A first product fails at the scope and at the second customer, not at the code. These four are written into the engagement for that reason.

The exclusions are written down.
What the first version does not do is agreed at the same moment as what it does. A scope with no stated exclusions is not a scope, it is an expectation, and the argument about it happens later at the worst possible time.
Customers separated, and the boundary attacked.
Enforced in the data rather than in the screens, then tested by signing in as one customer and reaching for another’s records. Where buyers ask which regime their data sits under, we answer before the build rather than in a questionnaire.
The code and the billing accounts are yours.
Opened in your entity’s name at the start rather than transferred at the end, because a product whose source and revenue sit in a supplier’s account is not yet an asset you can raise on. Ending an engagement is a permissions change.
We say when no-code would do.
If the open question is still whether anyone wants this, tools you rent answer it in weeks and a build answers it in months. Saying so costs us the project. A firm that never recommends the smaller option is not giving you an assessment.

Common questions

SaaS development, answered.

Generally through a distributor, a mainland branch or a permit rather than directly, and in Dubai the permit route runs under Executive Council Resolution No. 11 of 2025. For a product company that is not a legal footnote, it is the addressable market, which means it belongs in the first conversation rather than the legal review: it decides who the first customers can be, and therefore what the first version has to do. Which entity closes a deal also decides the tax treatment of it, and that is set out on the CRM page. One correction worth carrying into any conversation about founding here: the exemption people mean is available to a qualifying free zone person on qualifying income, not to free zone companies as a class.
FAQ · 01
Yes, and the choice follows where your customers are rather than where you are. Network International, Telr and PayTabs are the names a UAE finance team recognises, and a card charged from somewhere unfamiliar can sit in an approvals queue long enough to stall a renewal. For customers outside the country a global processor is simply better, and running both is common rather than a failure of decisiveness. What matters more than the logo is that the product issues a document the buyer will accept without an email exchange, from the first invoice. What your own company then owes on it is a separate subject, set out on the Dubai page.
FAQ · 02
It depends on one thing, and it is not the number of screens. A version that serves one company can be quick; a version that can take a second customer without a rebuild takes longer, and that difference is the whole reason this market quotes the same word at two weeks and at twelve. Ask any estimate which of the two it is describing. Ours is scoped backwards from a named buyer, with the exclusions written down, and it says plainly which parts are deferred until we know what people use. Nobody can give you a duration honestly without first telling you what is in it.
FAQ · 03
Not as a general rule, and you will still be asked in most enterprise conversations. The federal law reaches a controller or processor outside the country that processes the data of people inside it, so being hosted elsewhere does not put you outside it, and a customer licensed in DIFC or ADGM is answering to its own regime rather than the federal one. There are in-country options if a buyer’s obligations require one, and the specifics of what is available where are on the enterprise software page. Decide it before the build: migrating a live product for one contract is the expensive version of this answer.
FAQ · 04
Often, and it is the strongest starting position there is, because the hardest question in a product build has already been answered by somebody using the thing daily. Three things will be missing, and they are the same three every time: separation, so customer B cannot see customer A; a way to bill, because you have never had to; and everything that quietly assumed one company’s habits, its terminology and its exceptions. That is a defined piece of work rather than a rewrite. What it is not is a weekend, which is what the demo makes it look like. And where the tool is only ever worth having for you, improving it in place is the pillar’s subject rather than this page’s.
FAQ · 05
From the first commit, unless you can honestly say there will never be a second customer. It is the one part of the architecture that cannot be added quietly later: doing it afterwards means moving live accounts and their data while people are working in them, which is a migration with customers on it rather than a piece of engineering. Built in at the start it costs days. Added at fifty customers it costs a quarter and a difficult set of conversations. The exception is real, though: a product genuinely made for one organisation and priced that way should be built for one.
FAQ · 06
You do, and it matters more here than on most builds because an investor will look. The repository, the cloud account, the billing account and the domain go into your entity’s name at the start rather than being transferred at the end, so ending an engagement is a permissions change rather than a migration. The version that causes trouble in diligence is not usually a hostile supplier, it is a well-meaning one whose account the product happens to live in. Ask about it in writing before any product engagement, here or elsewhere.
FAQ · 07

Keep exploring

Explore AI and Automation Services

Part ofAI and Automation Services

AI Consulting

What your licence and data regime allow, ranked and costed.

Custom AI Development

Built where your own data beats a hosted model.

AI Chatbot Development

Answers from your documents, in the Arabic customers write.

AI Voice Agents

Agents that answer your published line, in Arabic and English.

AI Dialers

Outbound calling built inside the telemarketing rules.

WhatsApp Automation

Threads that finish in writing, in Arabic and English.

Business Process Automation

Rewrite the process for this market, then automate it.

Workflow Automation

Wire the two systems either side of the hand-off.

CRM Development

A CRM that knows which of your companies is selling.

Next step

Scope the version someone will pay for.

Tell us what exists and who has already said they would buy it. We will come back with the smallest version worth building, and what waits.

Tell us what you need.

What SaaS development decides first.

Many customers, one codebase.

The first version is a choice.

Billing is part of the product.

Six kinds of SaaS build.

A version somebody will pay for.

B2B, sold to companies.

Built for one trade.

Keeping customers apart.

White-label, and an API.

An internal tool made sellable.

Assembled, built for one, or built for many.

What MVP means in this market.

The same first version is quoted at two weeks and twelve.

A short quote usually leaves out billing and isolation.

UAE finance teams recognise some payment rails, not others.

Most products here began as an internal tool.

Inside a SaaS build.

The scope, and the exclusions.

The version they can pay for.

Billing, plans and invoices.

Separation between customers.

Seeing what customers use.

Hardening, and the handover.

Built with Stripe and PostgreSQL.

From a paying customer to a product.

Scoping the smallest paid version.

Building one workflow, with billing.

Hardening what customers reached.

Four promises about the build.

SaaS development, answered.

Explore AI and Automation Services

AI Consulting

Custom AI Development

AI Chatbot Development

AI Voice Agents

AI Dialers

WhatsApp Automation

Business Process Automation

Workflow Automation

CRM Development

Scope the version someone will pay for.