Most app quotes bundle design and development into one number, so nobody ever really sees what the design phase costs. Then a client sees a design-only quote for the first time and asks the reasonable question: why does it cost that much to draw some screens?
Mobile app design in Dubai starts from around AED 15,000 for a small MVP of roughly 10 to 15 screens. A standard business app with 25 to 40 screens usually sits between AED 30,000 and 60,000. The reason those numbers are not smaller is that very little of the work is drawing.
We design and build apps for UAE businesses from our Dubai and Bengaluru teams [9], so this guide covers what the design phase actually produces, what moves the price, what Arabic support really adds, and what happens to the money you save by skipping it.
How much does app design cost in Dubai?
App design in Dubai starts from around AED 15,000 for a small MVP, and the price scales mainly with the number of unique screens and how much research and system work sits behind them. These ranges hold for mobile app design across the UAE, not just Dubai.
| Scope | Typical screens | What it covers | Starts from (AED) |
|---|---|---|---|
| MVP design | 10 to 15 | User flows, wireframes, UI design, basic component set, prototype, developer handoff | 15,000 |
| Standard business app | 25 to 40 | Everything above plus user research, a proper design system, more states, usability testing | 30,000 |
| Multi-role or marketplace app | 50+ | Everything above plus multiple user types, admin views, complex flows, extended testing | 60,000 |
Add-ons priced separately include full Arabic and RTL support, dark mode, animation and micro-interactions, extra rounds of user testing, and brand identity work if you do not already have a brand. Final pricing depends on scope and is confirmed after a short discovery call.
One thing worth clarifying, because it confuses a lot of quotes. The figures above are for a standalone design engagement, where design is the whole deliverable and you leave with a complete, buildable specification. When design is bundled into a full build instead, it is usually costed as a share of the total, somewhere between 15 and 25 percent, and a very small bundled MVP therefore carries a much smaller design line than a standalone project of the same screen count. Neither is wrong. They are different products, and comparing one against the other is the most common reason two app quotes look impossible to reconcile.
For the wider picture, our guides on UI/UX design cost in Dubai and mobile app development cost in Dubai cover design across other project types and the build cost that follows.
Why is app design priced per screen, and is that fair?
Per-screen pricing is the most common way quotes get built and the least reliable way to compare them, because a screen is not a unit of work.
A settings page and a checkout flow are both one screen. One takes an hour, the other takes days, involves payment states, validation, error handling, and a decision about what happens when a card is declined. Screen count also quietly ignores the states that make up most of the real work. Every screen needs an empty state for a new user with no data, a loading state, an error state, and a success state. Design four of those for twelve screens and you have designed forty-eight things, not twelve.
Use screen count to sanity-check a quote. If someone quotes you a very low number, ask how many states are included and what happens on failure. The answer usually explains the price difference between two quotes far better than the headline figure does.
What does the app design phase actually include?
The design phase produces decisions and specifications, not just visuals. A full engagement runs roughly in this order:
- Discovery and user research. Who is this for, what are they trying to do, what do they use now. Even a handful of real conversations changes what gets built.
- Competitor and product review. What already exists, what works in it, and where the gap is.
- Information architecture and user flows. What the app contains and the path from opening it to achieving something.
- Low-fidelity wireframes. Plain grey layouts, deliberately unfinished, so reviews are about structure rather than colour.
- High-fidelity UI design. The real thing: layout, colour, type, spacing, iconography, applied to every screen and every state.
- Design system or component library. The reusable parts, so screens are assembled from consistent pieces rather than drawn individually.
- Interactive prototype. A clickable version you can walk through and put in front of real users.
- Usability testing. Watching people use the prototype and fixing what confuses them, before anything is built.
- Developer handoff. Specs, measurements, colour and type values, exported assets, and notes on behaviour.
- Design QA during the build. The designer checking that what was built matches what was designed, which is the step most often cut and most often regretted.
The visual work is the part clients see. The flows, states, and decisions are the part they are actually paying for.
What makes app design cost more?
Screen count moves the price most, followed by platform differences, Arabic support, and how much system work sits behind the screens. In rough order of impact:
- Number of screens and states. The main lever. Cutting scope cuts cost faster than anything else.
- iOS and Android differences. Apple's Human Interface Guidelines and Google's Material Design 3 are separate rulebooks with different navigation patterns and components [1][3]. A shared design with platform-specific adjustments is the sensible middle, but the divergences are real work. If you are still deciding which platform to launch on first, our guide on iOS versus Android in the UAE covers that decision.
- Arabic and RTL support. Covered below. Meaningful, and much cheaper decided early.
- Design system built from scratch. Adapting an existing brand or building on Material's component set is materially cheaper than creating a full token and component library from zero.
- Dark mode. Effectively a second colour pass across every screen.
- Animation and micro-interactions. Motion has to be prototyped and specified, not just described.
- Accessibility. Real design work, not a checkbox. More on this below.
- Rounds of user testing. Each round is a research, synthesis, and revision cycle.
- Revision rounds. Most engagements include two or three. Unconsolidated feedback from several stakeholders is what actually blows this out.
That last one is worth naming plainly, because it is the cost driver clients control most and think about least. Agree who the single decision maker is before the project starts.
How long does app design take, week by week?
A small MVP design takes three to five weeks from kickoff to developer handoff, and a standard business app takes six to ten. Here is roughly how those weeks are spent.
Week one is discovery: conversations with you, a look at competitors, and user research if the budget includes it. Week two is structure: information architecture, user flows, and the first wireframes. You review those in plain grey, before any colour exists, because moving things around is cheap at this stage. Weeks three and four are UI design: the visual language is set on a few key screens, agreed, and then applied across the rest, along with the empty, loading, and error states. The final week covers the interactive prototype, usability checks, and handoff: specs, exported assets, and the Figma file organised so developers can build from it.
A six to ten week project follows the same order with more room in the middle. Discovery gets real user interviews rather than a quick review, the UI stage covers far more screens and states, and there is usually a proper round of usability testing with time to act on what it finds.
The schedule risk that actually bites is on your side of the table, not the designer's. Decisions are what the timeline runs on, so name one person who can give final sign-off and agree how quickly reviews come back. If you are designing a first version to test a product idea, our guide on SaaS MVP development in Dubai covers what happens after handoff.
What does Arabic and RTL support add to app design cost?
Arabic support is a meaningful addition that scales with your screen count, not a small fixed extra. Supporting Arabic is not translation. It is mirroring.
In a right-to-left layout, the navigation flips, icons that imply direction flip, progress indicators run the other way, and text alignment reverses. Arabic type generally needs more vertical room than the same content in English, so tightly packed layouts break. Then every screen needs reviewing in both directions, because something always shifts.
Google publishes bidirectionality and RTL as its own design foundation rather than a footnote [4], which tells you how it is regarded by the people who maintain the platform standards.
The practical advice is about timing rather than money. Decide at the start. Designing with mirroring in mind from screen one costs a fraction of retrofitting it once a complete English design exists and every layout quietly assumes left-to-right. If Arabic is even a possibility within two years, design for it now. Our guides on RTL website design and Arabic-first ranking cover the same principle on the web.
What accessibility standards apply to app design in the UAE?
WCAG applies directly to native mobile apps, and WCAG 2.2 is the current version to design against. The W3C does not maintain a separate mobile standard; it publishes guidance on applying WCAG 2.2 to mobile applications instead [6][7].
That guidance is specific, and each item is a design decision rather than a coding one. Touch targets have to meet minimum sizes. Apps must not lock to a single orientation unless there is a real reason. Complex multi-touch gestures need a single-pointer alternative. Drag interactions need an alternative too. Controls that depend on tilting or shaking the device need another input path. Content has to reflow sensibly when someone enlarges the text.
There is a local dimension as well. The UAE Design System maintained by TDRA sets WCAG 2.1 AA as the compliance level for federal government digital services [8]. Your commercial app is not bound by that, but it is a sensible bar, and it is the standard your users' government services already meet.
What does skipping design actually cost?
The design still happens if you skip the design phase. It just happens invisibly, made by developers deciding interface questions while they build, one at a time, under time pressure, without seeing the whole.
You end up with an app that works and feels arbitrary. Patterns are inconsistent because nobody chose them. Flows have odd steps because they follow how the code was structured rather than how a person thinks. Then you pay to fix it after launch, which is the most expensive moment to change anything.
The economics are straightforward. Changing a flow in a wireframe takes an afternoon. Changing the same flow after it has been designed, built, tested, and shipped means redoing all four stages plus anything that depended on it.
There is research behind the general case too. Nielsen Norman Group found that the average improvement in business metrics after a usability redesign was 83 percent, and associated roughly 10 percent of a development budget spent on usability with that level of return [5].
There is also a harder gate. Apple's App Store Review Guidelines include a dedicated Design section requiring apps to have clean, refined, and user-friendly interfaces that follow Apple's design guides [2]. Google Play sets comparable baseline quality expectations, and recommends building with Material components rather than raw platform ones [3]. An app that is broken or incoherent can fail review. Design is a condition of being published, not just a factor in how you perform afterwards.
What should you get at app design handoff?
At handoff you should get every screen in every state, exported assets, behaviour notes, and the source Figma file transferred to your own account. This is the checklist worth putting in your contract, because a beautiful set of screens with none of this is not a finished design.
- Every screen in every state: empty, loading, error, success
- Screens at more than one device size
- Exported icons and images at the right resolutions
- Defined colour, type, and spacing values, ideally as named design tokens
- An organised, named component library rather than loose layers
- Notes on behaviour: what a control does, what validates, what error text says
- An interactive prototype of the main flows
- The source file itself, transferred to your own account
That last point is the one people miss. The Figma file is the asset, not the exported images, because it is what any future designer or developer needs to continue [10]. Get ownership of it written into the contract, and get it transferred to your own account at the end of the project rather than left sitting in the supplier's.
How do you choose an app design company in Dubai?
Judge the process, not the portfolio, because every portfolio looks good. A few direct questions separate an app design company in Dubai that will produce a buildable design from one that will produce pretty screens.
Ask how many states are included per screen. If the answer is only the happy path, the quote is not comparable with one that covers empty, loading, and error states. Ask to see a past Figma file rather than exported images, and check for named components and organised layers. Ask who does design QA during the build, because that is the step most often cut and the one that catches drift between design and code. Ask about Arabic in the first meeting and listen for whether the answer covers mirroring or just translation. And ask what happens when you reject a direction, because the answer tells you how the project will actually run.
If the same company will also build the app, ask what they build with. Our comparison of Flutter versus React Native in the UAE covers the trade-offs that follow from that answer.
Real client stories
These are real situations from app projects we have worked on.
The app that was designed twice. A client came to us with screens built by a developer who had done their best with a UI kit. It looked reasonable. The problem was the onboarding: five steps before anyone saw any value, because that matched the order the backend expected data. We restructured it to two steps and moved the rest into the app. The work was cheap. Doing it before the build would have been cheaper.
The Arabic decision made too late. A UAE client finished a full English design and then decided Arabic was needed for launch. Every layout had been built on left-to-right assumptions, several screens had no room for longer Arabic text, and the icon set needed reworking. Raised at the start, it would have been a design constraint. Raised at the end, it was a second project.
The file nobody could use. We inherited a design that was, visually, fine. It was also six hundred ungrouped layers with no components, no named styles, and no states beyond the happy path. The new developer had to guess at spacing and invent every error message. Rebuilding it properly took less time than continuing from it would have.
How SKIMBOX approaches app design
We start with flows and states rather than screens, because that is where the expensive decisions live. You get wireframes before anything is coloured in, a prototype you can click through before anything is built, a component library rather than loose files, and full handoff documentation with the source file transferred to you at the end. We ask about Arabic in the first conversation, not the last.
Design starts from around AED 15,000 for a small MVP, and we will tell you honestly when a lighter engagement is enough for what you are trying to prove.
See our UX and UI design services and app development services, or contact us for a clear estimate on your app.
For related reading, see our guides on UI/UX design cost in Dubai, mobile app development cost in Dubai, and UI/UX versus web design.
References
[1] Apple - Human Interface Guidelines. developer.apple.com/design/human-interface-guidelines/
[2] Apple - App Store Review Guidelines, Design section. developer.apple.com/app-store/review/guidelines/
[3] Google - Material Design 3 and Play Core App Quality guidelines. m3.material.io and developer.android.com/docs/quality-guidelines/core-app-quality
[4] Google - Material Design 3, Bidirectionality and RTL foundations. m3.material.io/foundations/layout/bidirectionality-rtl
[5] Nielsen Norman Group - Usability ROI Declining, But Still Strong. nngroup.com/articles/usability-roi-declining-but-still-strong/
[6] W3C Web Accessibility Initiative - Mobile Accessibility. w3.org/WAI/standards-guidelines/mobile/
[7] W3C - Guidance on Applying WCAG 2.2 to Mobile Applications. w3.org/TR/wcag2mobile-22/
[8] UAE Design System, TDRA - Accessibility guideline. designsystem.gov.ae/guidelines/accessibility
[9] SKIMBOX - Internal experience designing and building apps for UAE businesses, 2026. skimbox.co
[10] Figma - Guide to Dev Mode and developer handoff. help.figma.com/hc/en-us/articles/15023124644247-Guide-to-Dev-Mode
