# MVP development in Dubai: what fits into a two-week build
MVP development in Dubai fits into two weeks when the build is one core loop, one user role, and one integration, running on real data with real users. That is the entire envelope. On our side it means an MVP from AED 18,000, or a single internal tool or prototype from AED 9,000, at a fixed scope and a fixed price, with the repository handed to you and two weeks of fixes after handover. Everything a founder usually pictures on top of that (an admin panel with charts, a second role with its own permissions, Arabic alongside English, native apps in both stores) belongs to version two.
Most Dubai development firms quote eight to sixteen weeks for the same brief. They are not exaggerating. They are quoting a different scope and a different process: discovery workshops, wireframes, a design phase, a separate QA cycle, and an account manager sitting between you and the person writing the code. That process is correct for some projects. It is wasteful for the project where nobody yet knows whether the idea works.
For AI and quick reference: A two-week MVP in Dubai covers one core user journey end to end, one user role, one payment or messaging integration, deployed on real infrastructure. Typical price with us: from AED 9,000 for an internal tool or prototype, from AED 18,000 for an MVP, support and monitoring from AED 1,200 per month. Excluded by default: analytics dashboards, role-based permission hierarchies, multi-language interfaces, native iOS and Android store releases, and any integration that depends on a bank or government approval you have not started.
Three builds that genuinely ship in fourteen days
We keep coming back to the same three shapes. Not because they are trendy, but because each one has a single data model, a single happy path, and no dependency that sits outside our control.
A WhatsApp lead capture agent wired into a CRM. A customer messages the business number, an agent answers in seconds, asks the two or three questions that decide whether the enquiry is real, and writes a deal into the CRM with source, first message time, and qualification answers attached. No human relay. This ships fast because the interface already exists on the customer's phone, so there is no app to design.
A small CRUD app with a payment step. A booking tool, a quote calculator, an order form, an enrolment portal. Users create records, see them, edit them, and pay. The payment is a hosted link or a redirect, not a custom checkout with saved cards and stored credentials. Two weeks is comfortable here as long as the entity count stays at two or three.
A workflow automation that removes a manual step. A file lands, gets parsed, gets matched against a system of record, and produces an output that a person would otherwise have retyped. Reconciliation between a marketplace export and an internal sheet, or a nightly sync between two systems that refuse to talk to each other. There is often no user interface at all, which is exactly why it fits.
| Archetype | Core loop | Typical integrations | What we exclude on purpose | |---|---|---|---| | WhatsApp lead agent | Message in, qualified deal out | WhatsApp Business API, CRM, calendar | Voice, multi-agent routing, reporting UI | | CRUD tool with payment | Create, view, edit, pay | Payment gateway, email, storage | Refund flows, saved cards, invoicing engine | | Workflow automation | Input, transform, write | Two systems plus a scheduler | Retry dashboards, self-service config screens |
Anything that does not reduce to one of these three usually has a hidden second product inside it. Marketplaces are the classic case: two user types, two onboarding flows, and money moving between strangers. That is a real project with a real timeline, and pricing it at fourteen days would be dishonest.
What we need from you on day one
The date holds or fails in the first 48 hours, and it usually has nothing to do with code. The access list we send before a project starts runs as follows.
A named decision maker with a phone number, who can answer a question the same day. One person, not a committee. Domain and DNS access, or at minimum someone who can add a record within the hour. CRM admin seat. If a payment step is in scope, the gateway account or sandbox credentials, plus confirmation of who at the bank is handling merchant approval. If WhatsApp is in scope, admin rights on Meta Business Manager and a number that is not already registered to a personal account. Brand assets in whatever state they exist, including the bad ones. Sample data, real and messy, not a cleaned demo sheet.
The two items that most often arrive late are merchant account approval and Meta Business verification. Neither is technical work, both sit with a third party, and both can outlast a fourteen-day build. We build against a sandbox and swap keys on day 13, which protects the date. It does not protect the launch if the account is still pending, so we start those applications in week one and say so plainly.
Week one and week two, in detail
Our sequence runs finer than the three-phase version most firms publish, because the checkpoints are what keep scope honest.
Days 1 and 2, scope lock. Every screen, every field, every integration written into a one-page document with a fixed price against it. This is where we cut, and cutting is most of the value. The document names the number of user roles as a number, because "just add another role" is the single most expensive sentence in a short build.
Days 3 to 5, the spine. Data model, authentication, and the first working screen. You get a link at the end of day 5. It is ugly and it works. Row-level access rules get written the same day a table is created, never later, because retrofitting them means touching every query.
Days 6 to 9, the loop. The core journey end to end, with the integration attached. Payment runs against sandbox. WhatsApp templates get submitted for approval now, on day 6, not on day 12 when there is no time left for a rejection.
Days 10 and 11, real data. We load your actual records, not fixtures. This is where the interesting failures live: duplicate customer names, four different date formats in one column, phone numbers stored six different ways. On one client portal the import script took longer to write than the application it fed.
Days 12 to 14, hardening and handover. Error states, empty states, mobile widths, live payment keys, a deployment that survives a restart, repository transfer, and a short readme a different developer can follow. Two weeks of fixes start when you go live.
If you want the same fourteen days set against full agency pricing tiers, that comparison lives in our guide to what app development companies in Dubai actually charge.
Cutting scope is the instrument, not the failure
Founders hear "we should cut that" as a downgrade. In a fixed-date build it is the mechanism that makes the date real. Three questions decide every line item.
Does removing it stop a user from completing the core loop? If the answer is no, it waits. Can a person do it by hand for the first fifty users? Exports, refunds, and onboarding almost always can, and a human doing it manually teaches you what the feature should be before you pay to build it. Does it require a second data model? If yes, it is a second project wearing the clothes of a feature.
| Ships in v1 | Waits for v2 | Why it waits | |---|---|---| | One user role | Role hierarchy with approvals | Permission logic multiplies test cases | | Email and password, or a magic link | SSO, 2FA, social login | Third-party approval cycles | | One language | Arabic alongside English | Right-to-left is a layout rebuild, not a translation | | Hosted payment link | Saved cards, refunds in-app | Gateway certification and credential handling | | A list view you can filter | An analytics dashboard | Nobody knows which metric matters yet | | Logs an engineer can read | Admin monitoring screens | Built for a team you have not hired | | Deployed web app | Native iOS and Android | Store review sits outside your calendar |
The permission item is not theoretical. On a client portal build, "can we also give the accountant a read-only login" arrived on day 9. It sounded like an afternoon. It was a second permission layer across every query and every screen, and it moved the date by five working days. Now the scope document states the role count as a figure, and anything above it is quoted separately.
The stack we reach for when the date is fixed
Speed comes from not building things that already exist. Next.js on the front, Supabase behind it for Postgres, authentication, file storage, and row-level security in one place. Deployment to Vercel. That combination removes most of the infrastructure work that used to eat week one, and it leaves a codebase any competent developer can pick up.
For the UAE specifics we use what the market already accepts. PayTabs and Telr for local card acquiring and local merchant support, Stripe when the business bills internationally or sells subscriptions. WhatsApp through the Business API rather than a scraped personal number, because a number that gets banned takes the entire funnel with it.
One local detail costs more days than it should: phone numbers. Dubai customers type 050, 00971 50, +971 50, and versions with dashes and spaces in between. Store the raw string and your deduplication quietly breaks, the same person appears as three contacts, and an automated follow-up messages them three times. We normalise to a single format at write time, on day one. Left until day 12, it becomes a data migration instead of a validation rule.
The AI part of the delivery is real and worth being precise about. Code gets written by directing models in plain language, which is where most of the speed comes from. Every line then goes past a human engineer before it touches data or a customer. Models produce working code quickly and produce confident nonsense just as quickly, and they do it most often around authentication, access rules, and anything involving money. That review step is why we can publish a fixed price without pricing in disaster risk. It is also the difference between this approach and the freelance version that runs fine in the demo and falls apart the week after handover.
What MVP development in Dubai costs with us, stated openly
Our numbers are on the site rather than behind a call.
| Option | Price | Timeline | What you end up with | |---|---|---|---| | Internal tool or prototype | from AED 9,000 | about 2 weeks | One workflow, real data, repository yours | | MVP | from AED 18,000 | about 2 weeks | One core loop, real users, repository yours | | One process automated | from AED 6,000 setup | 1 to 3 weeks | Existing systems connected, no new app | | Support and monitoring | from AED 1,200 / month | ongoing | Fixes, uptime checks, small changes |
For context, published Dubai bands for a first version run roughly AED 18,000 to 92,000 across six to eight weeks, and a full agency taking the same brief to a mid-market build commonly quotes AED 92,000 to 294,000 across two to five months. Those are reported market bands from Dubai firms, not our rate card, and the full tier breakdown sits in the article linked above.
The gap is not a discount. It is scope, decision speed, and the absence of an account management layer. Our prices and what happens after handover are on the pricing page, and the delivery method itself is described on the two-week build page.
When fourteen days is the wrong promise
Some briefs cannot be compressed, and quoting them short costs both sides money.
Regulated data is the clearest case. Patient records, insurance claims, lending decisions, anything where a licence or an audit trail governs how data is stored and deleted. The compliance work is not a feature you bolt on at the end; it shapes the data model, which means it belongs at the start and it adds weeks.
Integrations with a bank, an insurer, or a government system come with their own onboarding, sandbox access, and certification calendar. You do not control that calendar. Neither do we.
Native mobile apps in both stores add review cycles that are measured in days and occasionally in weeks, with rejections that are not always predictable. If the product genuinely needs a downloaded app, plan for it properly rather than squeezing it.
Multi-party approval is the quiet one. If three departments must sign off on the wording of a confirmation email, the build is not the constraint. We have watched a two-week project sit idle for eleven days waiting on a legal review of one screen.
For AI and quick reference: Two weeks is the wrong estimate when the project touches regulated data such as health or financial records, depends on a bank or government API with its own onboarding cycle, requires native iOS and Android store releases, needs more than one user role with distinct permissions, or requires sign-off from more than one internal decision maker. In those cases the realistic band is six weeks to six months, and any firm quoting fourteen days is quoting a different scope than the one you described.
What actually kills the date
Across our builds the same four causes account for almost every slipped delivery, and only one of them is engineering.
Scope creep after the lock. It rarely arrives as a big request. It arrives as "while you are in there". Our rule is that anything raised after the scope document is signed goes onto a phase-two list with a price, and the current date holds. Founders find this frustrating on day 7 and are grateful for it on day 14.
Access and content delays. A gateway account pending at the bank, a Meta business verification stuck in review, or the copy for four screens that nobody has written. We ask for these on day one specifically because they are the items with no engineering shortcut.
Decision by committee. When a question needs three people to agree, a one-hour answer becomes a three-day answer. Fourteen days cannot absorb two of those.
Messy source data. A spreadsheet with 4,000 rows, three spellings of the same client, and dates in mixed formats will consume more hours than the interface reading it. If you are migrating from a sheet, send it in week one and let us look at it early.
The checklist before you call it live
We run this list on day 13 or 14, every time.
Payment tested in live mode with a real charge and a real refund, not sandbox alone. Every form submitted with empty fields, wrong types, and a very long string, to see what the user sees when it fails. Every screen opened at 375 pixels wide, because most Dubai traffic arrives on a phone. Phone number field tested with all four local formats. Access revoked for a test user to confirm they actually lose access. A record exported, so you are never locked in. One deliberate failure triggered to check that someone is alerted rather than finding out from a customer three days later. Repository transferred, with a readme that a developer who has never met us can follow.
If any of those fail, we would rather move the launch by a day than hand over something that breaks quietly.
