Ask for an app quote in Dubai and you will get numbers that seem impossible to reconcile. Part of that is margin and part is capability, but most of it is that the quotes are not describing the same work. Some include design. Some assume you already have it. Some include it in a line called "UI" that turns out to mean applying a template.

Knowing which half you are buying makes the numbers comparable.

What design actually produces

Design is the decision-making layer. Before anything is built, somebody has to determine what the app does, in what order, and what happens when it goes wrong. That produces:

• Flows. Every path through the product, including the unhappy ones — no connection, expired session, payment declined, empty state on first open.
• Screens. Every state of every screen, not just the ideal one. A list has an empty state, a loading state, an error state and a state where one item has a forty-character name.
• A component library. So the tenth screen costs less than the first, and so two developers build the same button the same way.
• A prototype. Something you can hold and tap before anyone writes code, which is when changes are still cheap.

What development produces

Development turns those decisions into a working product: the front end, the back end, integrations, app store submission, and the long tail of device-specific behaviour that only appears on real hardware.

Good development teams make design decisions when they have to. They would generally rather not, because every decision made at build time is made under time pressure by someone whose job is something else.

Why the split matters for what you pay

The two are priced on different things. Design is priced on how much has to be decided — the number of distinct flows and screens. Development is priced on complexity: integrations, back-end work, the number of platforms.

That means a visually simple app with three payment providers and an ERP integration can cost more to build than a visually rich one that talks to nothing. And an app with forty screens costs more to design than one with eight, even if both are technically trivial.

When you compare quotes, establish which half each covers before comparing the totals. A quote that is half the price of another is frequently half the work.

Skipping design does not save the money

It moves it. Decisions still get made, but later, by developers, under deadline, one screen at a time. The usual results are familiar: the app works but feels inconsistent, because nobody decided the rules; changes cost more than they should, because there is no component library; and the second phase requires rework of the first.

The cheapest version of this mistake is a prototype nobody tested. The expensive version is a product that shipped, failed to hold users, and cannot be explained — because there is no record of what was intended, only what was built.

Who to bring in first

Design first, almost always. Not because we are designers, but because the output of design is the input to an accurate development quote. Developers asked to price "an app" will either pad the estimate to cover the unknown or quote low and recover it in change requests.

Give three development teams the same set of flows and screens and you will get three comparable numbers for the first time.

Where we fit, honestly

We design. We do not build. Every project is led and delivered by a senior designer, and we work alongside your development team through build and design QA so the finished product matches what was designed.

If you do not have a build team, we can introduce you to a Dubai development partner we work with regularly. We would rather tell you that plainly than imply we do everything.

You can see how we approach mobile app design and app and web UI, and the questions we get asked most covers how we scope and what it costs.