The most expensive custom software is the software that should never have been built. Somewhere out there is a business paying tens of thousands for a system that does roughly what a subscription product does for a few hundred dirhams a month, because nobody asked the question early enough.
So this guide starts with that question, then answers the money one. Custom software in Dubai starts from around AED 15,000 for a focused first version, and rises sharply with integrations, user roles, and features. Below is how it is priced, what actually drives the cost, when off-the-shelf is the smarter buy, and the ownership terms that decide whether you truly own what you paid for.
We build custom software for UAE businesses from our Dubai and Bengaluru teams [5], so this is the version of the conversation we have before quoting anything.
Should you build custom software at all?
Buy off-the-shelf whenever a good product already does the job. Subscribing is almost always cheaper and faster than building, and a product used by thousands of businesses has been debugged by thousands of businesses. Custom software should have to earn its place against that default.
It earns its place in a few specific situations:
- Your process is a competitive advantage. If how you do the work is part of why you win, bending it to fit a generic product gives that advantage away.
- No product fits without painful compromises. Not "no product is perfect," but "every option forces us to break something that works."
- Your systems do not talk to each other and no product bridges them, so people retype data between systems all day.
- Licence costs at your scale exceed the build. At enough users, per-seat subscriptions can genuinely cost more than owning the thing.
- A manual process is eating real hours every week and will keep doing so.
If none of these apply, a subscription product is the better spend, and an honest developer will tell you so. If some do, the rest of this guide is for you.
Build vs buy: comparing the real costs
The only honest way to settle build vs buy is to price both over three years, because a subscription looks cheap in month one and a build looks expensive in month one, and neither of those is the number that decides anything.
Here is the frame. For buying: take your seat count, multiply by the monthly fee per seat, multiply by 36 months, then add the one-off setup or onboarding fee and any paid add-ons you will actually need, including the modules the sales demo quietly left out. For building: take the build itself, from around AED 15,000 for a focused first version, then add yearly maintenance and hosting for three years. Put the two totals side by side. Our build vs buy guide works that three-year comparison through with real seat prices. Put your own seat count and your vendor's price list into the same frame, because those two inputs are the ones only you have.
The crossover is usually about headcount. At five or ten users a subscription almost always wins, because you are sharing the cost of a mature product with thousands of other companies. As seats grow, the subscription line grows with them and the build does not. The second crossover has nothing to do with headcount: you are paying for three overlapping tools, each doing part of the job, and your team is retyping data between them. Three subscriptions plus the manual work of joining them up is often more expensive than one system that covers the whole process.
There is a third route people forget. Subscribe to the product, and build only the small piece that is genuinely yours. That is what one of our own clients ended up with, and the story is further down this page: a standard CRM covered nearly everything they needed, one unusual step did not, and a small integration handled it. Bespoke software for the ten percent that is specific to you, off-the-shelf for the ninety percent that is not. It is usually the cheapest answer and almost nobody asks for it.
Low-code and no-code tools sit in the middle. For internal forms, simple approval flows, and dashboards over data you already hold, they are genuinely good and much faster than writing code. They run out of room at three points: complex permissions, where different roles need to see different slices of the same record; deep integrations, where you need real error handling rather than a happy path; and pricing, because most of these platforms charge per user too, so at scale you land back in the licence problem you were trying to escape. When a business outgrows one, that is the step our product engineering services are for.
What does custom software cost in Dubai?
A focused first version starts from around AED 15,000. The price then scales with how much business logic the system has to hold.
| Scope | What it covers | From (AED) |
|---|---|---|
| Focused first version | One workflow, a small number of roles, no heavy integrations | 15,000 |
| Business system | Several roles, a few integrations, custom interface, reporting | 60,000 |
| Larger platform | Many integrations, high usage, compliance requirements | Scoped in discovery |
It is worth understanding why this sits above our mobile app development cost figure of around AED 10,000 for an MVP and our website development cost figure of around AED 3,500. A website mostly presents information. A thin app MVP proves one idea. Custom business software has to hold your actual rules: roles and permissions, data validation, workflow states, reporting, and integrations. That logic is invisible from the outside and is where the work lives.
Final pricing depends on scope and is confirmed after discovery. Services carry the standard 5 percent VAT [3], and the Federal Tax Authority publishes guidance on how VAT applies to services [4].
How is custom software priced?
There are three models: fixed price, time and materials, or a paid discovery followed by a mix of both. The right one depends on how well-defined the work is.
Fixed price quotes a set amount for a defined scope. Good for budget certainty, awkward for change, since every addition becomes a variation.
Time and materials bills for work actually done. Good for evolving scope, less certain on the total.
A paid discovery, then a fixed first phase, then time and materials is the pattern that works most often. Discovery turns a rough idea into a defined scope: the process mapped, features and roles agreed, technical approach decided, and a realistic estimate produced. Paying for it is a good sign rather than a red flag, because it means the estimate rests on analysis. The test of a good discovery is what you keep: documentation you own and could hand to another developer.
What drives the cost?
Integrations, the number of user roles, and the number of features move the price more than anything else. In rough order of impact:
- Features and screens. The obvious one, and the easiest to control by narrowing the first version.
- Integrations. The most underestimated. Connecting to a payment gateway, an accounting system, or a government portal is often more work than the feature it enables.
- User roles and permissions. Every distinct role multiplies the states the system has to handle correctly.
- How custom the design is. A functional interface built on a component library costs less than a bespoke one.
- Whether it needs mobile too. A web system plus native mobile is two delivery surfaces, not one.
- Compliance requirements in regulated sectors, which shape the architecture rather than sitting on top of it.
The lever you control most easily is the first one. A narrower first version that ships and gets used beats a complete system that arrives late and turns out to be wrong about something important.
How long it takes and how you pay
A focused first version takes two to four months from discovery to launch, and a fuller business system with several modules and integrations takes four to nine. Larger platforms take longer than that and are delivered in phases, so something is live and useful before the whole thing is finished.
The biggest variable inside those ranges is not how fast anyone writes code. It is how quickly your side answers questions. Custom software is assembled out of decisions about how your business actually works, and every decision that waits a week for a meeting adds a week. Naming one person who can settle a question without convening a committee will shorten the project more than any technical choice will.
Payment should follow the same logic. A deposit tied to discovery, then staged payments across the build, each one released against something you can see running. Never pay 100 percent upfront, because you have no leverage left if things go quiet. Never agree to 100 percent at the end either, because no developer can fund months of work out of pocket, and the ones who agree to it are usually planning to cut corners somewhere you will not see until later.
A milestone should be a thing, not a date. "End of March" is not a milestone. "The approval workflow runs end to end with three roles, on a demo link we can log into" is a milestone. Tie the money to demonstrated working software and the project reports on its own progress without anyone having to ask. A developer who resists that framing has told you something useful for free.
Agree the warranty in writing before work starts, too. A defect-fix period after launch is normal: for a set number of weeks or months, anything that does not behave the way the agreed specification says gets fixed at no extra charge. The other half of that clause matters just as much. Write down what counts as a defect and what counts as a change request. A wrong total on an invoice is a defect. Wanting invoices in a second currency is a change. Without that line, every new idea turns into an argument about whether it was already covered. And a warranty is not maintenance. It ends, and what comes after it is the running cost covered further down this page.
Who owns the code? The clause that matters most
Do not assume you own the source code. In practice you own it where the contract assigns the intellectual property to you in writing, and paying for development does not by itself transfer ownership. Copyright in the UAE sits under Federal Decree-Law No. 38 of 2021 [11], and it is the wording of your contract that decides your position, so have it checked. This surprises people every time, and it is the single most consequential term in a custom software contract.
You need two things in writing. First, an explicit assignment of the intellectual property in the code, designs, and documentation to you on payment. Second, the code in a repository your business owns, with the developers given access, rather than the developer holding the only copy and handing something over at the end.
Insist on regular commits to your own repository rather than one delivery on the final day. It costs nothing to set up and it changes everything about your position later. If you ever want to change developers, whether that transition costs you some time or your entire investment is decided by this one arrangement. Our guide to choosing an app development company covers the same ownership principle for apps.
While you are at it, insist on documentation as a deliverable: technical documentation for how the system is built and deployed, and user documentation for the people who operate it. Documentation is what lets a different developer pick your system up later instead of rebuilding it.
Software is a running cost, not a purchase
The build is the beginning of the spending, not the end of it. Budget from the start for:
- Hosting, usually usage-based. Our UAE hosting guide and cloud migration guide cover where to run it.
- Maintenance and bug fixes, commonly budgeted as a percentage of the original build cost each year.
- Security patching of the frameworks and libraries your software depends on, which is not optional.
- Third-party service and licence fees.
- Support for the people using it, and small changes as the business evolves.
A common way to budget maintenance is a percentage of the original build cost each year. The exact figure matters less than having one, because unmaintained custom software accumulates security and compatibility problems quietly, and then one day a dependency update breaks something and nobody knows how the system works.
The UAE-specific parts
Personal data brings obligations. If your software stores staff or customer records, UAE Federal Decree-Law No. 45 of 2021 requires you to secure that data, keep it confidential, and have a lawful basis for processing it, and it governs transferring personal data out of the country [1]. Practically: access control, a deliberate decision about hosting region, and advice if the data is sensitive. The UAE's wider cyber laws also apply to systems holding business and personal data [2]. Our PDPL compliance guide covers the detail.
Hosting region is a real choice. Cloud providers let you pick the region your data sits in, and both AWS and Microsoft Azure run regions inside the UAE [6][7], so keeping data in-country is possible if you want it.
Regulated sectors have their own rules. Financial services fall under Central Bank of the UAE requirements covering outsourcing and the use of cloud services for core activity [8], health data sits under separate legislation, and DIFC and ADGM businesses have their own data protection regimes [9][10]. Raise these at discovery, because they shape the architecture rather than bolting onto it, and confirm your own position with the regulator or a legal adviser.
Real client stories
These are real situations from software projects we have worked on.
The system that should have been a subscription. A client asked us to build a custom booking and scheduling system from scratch. Two questions into discovery it was clear that a standard product covered almost everything they needed, and that the one genuinely unusual part, how their pricing changed by season, could be handled with a small integration. We built the integration instead of the system. It cost a fraction of the original brief, and they ended up with something better supported than we could have built for the money.
The integration nobody had priced. A business approved a build where a single line in the brief said "connects to our accounting system." That connection turned out to require reconciling two different data models and handling failures on both sides, and it became a larger piece of work than several visible features combined. Discovery would have caught it. Now we scope and price each integration on its own, rather than letting one line in a brief stand for it.
The repository nobody owned. A client wanted to move developers and discovered the code lived only in the previous developer's private account, with no documentation. Recovering it took negotiation, and rebuilding the deployment process took weeks. Everything they have built since sits in a repository in their own name, with commits going in from day one.
How SKIMBOX approaches custom software
We start by asking whether you should build at all, because recommending a product you can subscribe to is sometimes the most useful thing we do. When building is right, we offer a paid discovery that leaves you with documentation you own, quote a focused first version rather than a sprawling one, will commit code to a repository in your name from the first week, will put the IP assignment in your contract, and price maintenance and hosting openly so software does not look like a one-off purchase.
A focused first version starts from around AED 15,000, with larger systems scoped after discovery. Final pricing depends on scope.
See our product engineering services and app development services, or contact us to talk through what you need.
For related reading, see our guides on mobile app development cost in Dubai, SaaS MVP development in Dubai, and choosing an app development company in Dubai.
References
[1] U.AE Official UAE Government Portal - Data protection laws, Federal Decree-Law No. 45 of 2021. u.ae/en/about-the-uae/digital-uae/data/data-protection-laws
[2] U.AE Official UAE Government Portal - Cyber laws. u.ae/en/Resources/Cyber-laws
[3] Federal Tax Authority, UAE - Value Added Tax. tax.gov.ae/en/taxes/vat.aspx
[4] Federal Tax Authority, UAE - VAT guides and public clarifications. tax.gov.ae/en/taxes/vat/guides.references.aspx
[5] SKIMBOX - Internal experience building custom software for UAE businesses, 2026. skimbox.co
[6] AWS - United Arab Emirates data privacy and PDPL, region and data-residency controls. aws.amazon.com/compliance/uae_data_privacy/
[7] Microsoft Azure - Azure regions list, including UAE North and UAE Central. learn.microsoft.com/en-us/azure/reliability/regions-list
[8] Central Bank of the UAE - Regulations, standards and circulars. centralbank.ae
[9] DIFC - Data Protection Law No. 5 of 2020. difc.com
[10] ADGM Office of Data Protection - Data Protection Regulations 2021. adgm.com
[11] U.AE Official UAE Government Portal - Intellectual property and copyright, Federal Decree-Law No. 38 of 2021. u.ae
