A clickable prototype takes fourteen days, and roughly three of them are drawing screens. On our side the tier starts at AED 9,000 for a fixed scope: three days of discovery, four days of flows and screens, three days of assembly, and four days of putting the thing in front of people who have never heard the idea. On day 14 you hold an interactive prototype a customer can tap through, test notes with the exact moments people hesitated, and a build scope any developer can quote from. There is no production code in it. That is deliberate.
Every Dubai development firm publishes a process page with four to seven stages and a bracket of four to eight weeks. Almost none of them tell you what you personally have to decide on Tuesday of week one, or what lands in your inbox on the last day. That gap is where two-week projects die, because a prototype schedule is not limited by design hours. It is limited by how fast one person answers a question and how quickly six real users can be lined up.
A clickable prototype in Dubai is an interactive mock-up of a product: real screens, the real words you will use, tappable hotspots, and fake data. A person can complete a whole journey inside it, and nothing is saved anywhere. It answers whether users understand the flow and want it. It does not prove the system can be built, and it contains no production code. With us it starts at AED 9,000 for a fixed scope and runs about two weeks.
A clickable prototype, a proof of concept and an MVP are three different purchases
These three get sold interchangeably in Dubai, usually by whoever wants the bigger invoice. They answer different questions.
A clickable prototype answers a demand question. Does a plumber in Al Quoz understand what this screen wants from him, and will he finish the journey without calling you? It is front-of-house only. We hand it over either as a high-fidelity interactive file with working hotspots, or as a deployed front-end shell with mock data, depending on how you plan to test it. Either way there is no database and no live integration behind the buttons.
A proof of concept answers a feasibility question, and it usually has no interface at all. Can we read this ERP through its API at all. Can a model classify these Arabic voice notes reliably enough to route them. That work is a technical spike, and building pretty screens on top of it wastes the budget.
An MVP is a working product with real users, real data and real money moving. It has login, a data model, and someone accountable when it breaks at 2am. Our MVP tier starts at AED 18,000, fixed scope, and the full breakdown of what that buys sits on the build page. Reading that alongside this piece is the fastest way to work out which of the two you are actually buying.
The order matters less than people think. If you already know customers want the thing and the only open question is whether they will pay, skip the prototype and build the smallest real version. If you are about to hand an agency AED 40,000 or more for a first version, on the usual three-to-six-month clock, two weeks of prototype first is cheap insurance against screens nobody has validated.
Week one, days 1 to 3: discovery, and the four decisions we need from you
Discovery is not a workshop with sticky notes. It is a short interrogation with a written output.
Day 1
Ninety minutes on a call, then we write. The questions that take the longest to answer are always the same four. Who is the user, named as a real person you can call rather than a segment. What do they do instead today, in detail, including the WhatsApp thread and the spreadsheet. What single decision does this prototype have to settle. And what would count as a failure, stated before we start, so nobody moves the goalposts on day 13.
By the end of day 1 you have a one-page problem statement and a ranked list of assumptions. Ranking rule: if this assumption is wrong, does the product still exist. The top two or three assumptions are what the prototype gets built to test. The rest wait.
Day 2
We map the process as it actually runs, not as the org chart says it runs. That means screenshots of the real sheet, the CRM stage names in the client's own wording, and the messages a customer sends at 11pm. On a booking flow this is where we usually find out that half the enquiries arrive with a voice note and a photo, which changes the first screen entirely.
Day 3
Scope lock. Screen count as a number. Flows as a number. Roles as a number. The price is fixed against that document, and it stays fixed. Four decisions come from your side by the end of day 3: which single user segment we build for, which one journey we prototype, whether Arabic is in scope for this round, and who has final say on the cut list. That last one sounds procedural until three people disagree about a button label on day 11.
Arabic deserves its own sentence. Right-to-left is a layout rebuild, not a translation pass, and adding it doubles the screen count on the critical path. In a two-week prototype we normally test in one language and note the RTL work for the build phase.
Week one, days 4 to 7: flows, wireframes and the cut list
Days 4 and 5
User flows first, written as numbered steps with the decision points named. Then low-fidelity wireframes: grey boxes, correct hierarchy, and the real words. We write the actual button labels, the actual error messages, and the actual price line at this stage, because copy is where people stall. In our own studio booking flow, testers did not hesitate at the layout. They hesitated at a deposit line that said "50% now" instead of the amount in AED. Two words, and the drop-off moved.
Low fidelity exists so you can say "wrong direction" cheaply. Killing a grey box costs twenty minutes. Killing a finished screen with brand colours costs half a day and someone's ego.
Day 6
Feature prioritisation, done out loud with the cut list on screen. Three tests decide each item. Does removing it stop the user finishing the journey. Can a human do it by hand for the first fifty customers. Does it need a second data model, because if it does, it is a second product wearing the clothes of a feature.
Everything cut goes onto a phase-two list with a note about why, so it stops coming back. Founders find this uncomfortable on day 6 and quote it back to us on day 14.
Day 7
High fidelity, and only for the screens on the critical path. Usually that lands between six and ten screens. You get one consolidated review window of 24 hours, with comments in one place. Feedback arriving as three separate WhatsApp threads and a voice note is the single most reliable way to lose a day.
Week two, days 8 to 10: building the clickable prototype
Assembly is the part everyone pictures when they hear the word prototype, and it is the shortest phase.
Days 8 and 9 go into hotspots and states. Every tap that a tester will make needs a destination, including the wrong taps. States matter more than screens: empty, loading, error, success, and the awkward one where a form is half filled and the user leaves. A prototype that only shows the happy path tests nothing, because in real use the happy path is the rare case.
Fake data has to be believable or the test breaks. That means Emirati and expat names people recognise, 971 numbers in the format customers actually type, AED amounts that match your real price list, and Dubai locations rather than Lorem Ipsum. We build at 375 pixels wide first, then check desktop, because most traffic here arrives on a phone held in one hand.
Day 10 is our own walkthrough. Two people on our side try to break it and note every dead end. We would rather find fourteen broken hotspots ourselves than have a tester find the first one and lose confidence in the whole thing. This whole method, AI writing the assembly fast with an engineer reviewing before anything ships, is described on the two-week build page.
Week two, days 11 to 14: testing on real people, fixes, handover
This is the part the agency process pages skip, and it is why the prototype exists.
Showing the prototype to your co-founder is a demo. Usability testing is a different exercise. Day 11 is set aside for it: we run five or six sessions of 20 to 30 minutes with people who match the user description and have never seen the idea. Not staff, not your investor, not the friend who says everything looks great.
Each session is task-based. "Book a studio slot for Thursday afternoon and pay the deposit." Then silence. The moderator does not explain, does not rescue, and does not answer questions until the task is finished or abandoned. What we record is where the hand hovers, what gets read twice, which word gets misinterpreted, and what the person says they expected to happen next. Five sessions is enough to see the same wall hit repeatedly. If two or more people trip on the same thing, it is a design problem. If one person trips, it may just be that person.
Days 12 and 13 are fixes on what testing surfaced, plus a second short pass on the two heaviest changes if the schedule allows.
Day 14 is developer handover, and here is the full list of what leaves our side:
- The clickable prototype as a share link that works on a phone with no login.
- The editable source file, in your ownership, with layers named so a stranger can work in it.
- User flows exported as a diagram, including the branches we cut and why.
- A build scope document: screen inventory, every state, every data field, and the validation rules we already know about, such as phone number formats.
- Test notes per session with timestamps against the recording, plus the ranked list of what broke.
- A one-page decision memo: build it, change it, or stop. With a reason.
That last document is the one clients read twice. A prototype that concludes "do not build this" saved the budget it cost.
Who does what: the responsibility split
Two weeks holds or slips on this, so we put it in writing before day 1.
Your side owns five things. One named decision maker with a phone number who answers the same day, not a committee. Source content, meaning your real price list, real service names, and any legal wording that has to appear. Sample data in whatever messy state it exists, including the duplicated rows. Five or six testers confirmed by day 9, ideally from your own customer base. And one consolidated review inside the 24-hour window on day 7.
Our side owns the rest. Facilitating discovery and writing the problem statement. Flows, wireframes, and high-fidelity screens. Prototype assembly with all states. Writing the test script and moderating every session so nobody leads the witness. Notes, the ranked findings, the fixes, and the handover pack.
The item that slips most often is testers. Recruiting six strangers in Dubai who match a niche B2B profile can genuinely take a week, and no amount of design speed compensates. If your customer list is reachable on WhatsApp, that problem disappears in an afternoon. If it is not, tell us on day 1 and we plan the recruitment into week one instead of discovering the gap on day 10.
What a clickable prototype costs in Dubai
Our number is published rather than quoted after a discovery call. A clickable prototype sits in the same tier as an internal tool: from AED 9,000, about two weeks, fixed scope, with handover and a two-week window for fixes afterwards. An MVP with login, real data and payments starts at AED 18,000. If the idea itself is still unformed, the Growth Audit at AED 3,000 is the cheaper first step, because it works out which process is worth prototyping at all. Full breakdown of every tier sits on the pricing page.
Five things move the price inside that band. The number of screens on the critical path, which is the main driver. The number of user roles, since two roles means two journeys and effectively two prototypes. Arabic, for the RTL reason above. Whether testers have to be recruited from cold or come from your list. And whether you want the prototype deployed as a front-end shell rather than an interactive file, which adds hosting and a little build work.
One boundary worth stating plainly: the moment the prototype has to read or write live data through a real API, it stops being a prototype. That is the MVP tier, and pricing it as prototype work would be dishonest about what has to be engineered. Hosting, API usage and licences are paid at cost from your own accounts, never marked up.
When two weeks is the wrong promise
Four cases, and we say so before taking the brief rather than on day 12.
More than one user role with genuinely different journeys. A two-sided marketplace is two prototypes and two rounds of testing, so plan three to four weeks or cut to one side for round one.
Products where the interface is only part of the process. Anything with a physical step, a delivery driver, or hardware needs the offline part observed before screens make sense, and observation takes days you cannot compress.
Regulated data flows. When rules govern what may be shown, stored or deleted, those constraints shape the screens, which means somebody reads them properly first. That reading happens before design, not during.
No access to users. If you cannot reach six people who match the profile within the two weeks, you will end up validating the prototype with colleagues, which produces a confident answer that is worth nothing. Better to spend week one on access.
There is also the case where a prototype is the wrong artefact entirely, because the real bottleneck is an internal process rather than a customer-facing product. Our comparison of when to build an internal tool versus an MVP covers that fork.
Where to start
If the idea is clear and the journey fits one user and one path, the fastest route is a fixed-scope two-week prototype at AED 9,000, and it starts with a 90-minute call and the four questions from day 1.
If you are still unsure whether the problem is worth software at all, spend AED 3,000 on the audit first. It has stopped more builds than it has started, which is the point.
We run this process on ourselves. The operator screens for our own studio booking flow were prototyped and tested before anyone wrote the state machine behind them, and two of the screens in that first version never made it into the build.
