Your MVP was the cheap part. Founders across the Gulf keep insuring the wrong half of the build — three months budgeted for the product, three weeks for "going live," and then six months spent inside those three weeks.
That gap has a name in my head: the production wall. A production wall is the point where every convenient assumption a prototype made — one tenant, one currency, one language, one test-mode card — fails at the same time, in front of a paying customer.
It is not a failure of AI builder tools. Lovable and Replit do exactly what they promise, and they do it startlingly well. The trouble is that what they know how to build is the global default, and the Gulf is not the global default.
Three beliefs that turn a working demo into a stalled product
I hear the same three sentences in Dubai, Abu Dhabi and Riyadh, usually from smart people who have already shipped something impressive.
"The payment integration is a weekend of work"
Fair — in San Francisco it nearly is. Stripe's documentation is superb, the sandbox behaves, and an AI builder has read all of it.
Inside the GCC the same task splits into a licensing question, a scheme question and a settlement question before a single line of code matters. Which entity holds the funds. Whether the card is a mada card in Saudi Arabia, a KNET card in Kuwait, a Benefit card in Bahrain, or an international scheme card issued in the UAE. Who owns the merchant record. Those answers change the integration, and no prompt has them.
"Arabic is a translation task"
This is the belief that costs the most, because it looks finished long before it is. Swap the strings, add dir="rtl", ship.
Then the progress bar still fills from the left, the back arrow points the wrong way, the currency symbol lands on the wrong side of the number, and a form built with hard-coded margin-left collapses. Arabic is a layout system, not a string table.
"Multi-tenant means adding a tenant_id column"
The column is the easy fifteen minutes. Enforcing it on every query, every background job, every export, every admin screen and every future feature written by someone who joined nine months later — that is the actual work, and generated code almost never does it at the database layer.
Why do Gulf payment integrations fail on AI-generated code?
Gulf payment integrations fail on AI-generated code because the model writes the pattern it saw most often — a Stripe-style card form, a single currency, a webhook that trusts its own payload. Regional gateways such as Tap Payments, Checkout.com and Moyasar use different tokenisation, different 3-D Secure flows, and different settlement timing.
The difference is not cosmetic. A mada transaction in Saudi Arabia routes domestically under rules published by SAMA; an international scheme transaction on the same checkout page does not. Two rails, two refund behaviours, two reconciliation files, one order table that was designed assuming there would only ever be one of each.
I once spent a Thursday on a call with a Dubai founder whose checkout had worked perfectly in test mode for six weeks. On the first live day, refunds started failing — not all of them, roughly the ones from a single bank. The generated code had stored the gateway's transaction reference and thrown away the acquirer reference, because in the tutorial it copied, there was only ever one identifier worth keeping. Nothing had errored. Nothing had warned. The data simply was not there, and the only fix was to re-import a settlement file by hand while the support inbox filled up. We have repaired that same missing field often enough that it is now the first thing my team greps for.
| Do not let your product become the merchant of record by accident. Decide early whether you hold funds or a licensed provider does, because that single choice changes your entity structure, your contracts and your integration. Retrofitting it after launch means migrating live customers between merchant accounts. |
What does Arabic-first UX actually require beyond an RTL flag?
Arabic-first UX requires mirrored layout, not translated text. Direction, alignment, icon orientation, chart axes, form field order, numeral shaping and date formatting all change, and each is a separate decision. Setting dir="rtl" flips the document; it does not flip a component whose spacing was written with physical properties like margin-left instead of logical ones.
The practical repair is not glamorous. Replace physical CSS properties with logical properties so margin-inline-start does the right thing in both directions. Choose a typeface that carries real Arabic weights rather than a fallback. Decide whether your numbers render as Arabic-Indic or Western digits, and be consistent about it in the app, the invoice and the SMS.
And then the part everyone forgets: content. A bilingual product needs an editorial workflow, because an Arabic string that is 40% longer than its English source will break a button that was pixel-fitted to the English.
The principles that actually decide whether a Gulf MVP survives
Strip away the tooling argument and four things separate the products that scale here from the ones that quietly get rewritten.
Boundaries belong where they cannot be forgotten. Tenant isolation enforced with Postgres row-level security survives a new developer, a new feature and a rushed Thursday. A filter in a service layer does not.
Money code needs reconciliation before it needs features. If you cannot answer "what did we actually receive yesterday, by rail, in AED and SAR" from your own database, you do not have a payment integration. You have a payment demo.
Compliance is architecture, not paperwork. As SDAIA has set out, Saudi Arabia's Personal Data Protection Law has been enforceable since September 2024, and the UAE's Federal Decree-Law No. 45 of 2021 sets its own obligations. Where data sits, and who can reach it, is a schema decision.
The second market is a design constraint, not a phase two. A UAE product that plans to enter Saudi Arabia should carry per-country configuration from the first schema. I watched one team lose the most expensive week I can remember to exactly this: they moved their database to a UAE region on a Monday, learned on the Wednesday that their first Saudi client needed residency inside the Kingdom, and moved it again on the Friday — with customer data live in both places in between.
| A prototype is a question you asked the market. Production is the promise you make once the market answers yes — and promises in this region are written in Arabic, settled in mada, and audited by someone who will ask where the data lives. |
A four-week sequence from prototype to production
This is the order my teams work in, and the order matters more than the speed. Doing week three first is how projects lose a quarter.
- Week one — establish the truth. Read the generated code rather than the demo. Map every external call, every place a secret is used in the browser, every table without a tenant boundary. Write down what the product actually promises a customer, and check the code makes that promise.
- Week two — fix the data boundary. Move isolation into the database. Add audit columns. Decide residency, then choose the region, then move the database — in that order, because the reverse means moving it twice.
- Week three — build the real payment path. One gateway, both rails, live keys, real settlement reconciliation, refunds and partial refunds tested against actual bank behaviour rather than a sandbox that always says yes.
- Week four — make Arabic first-class. Logical CSS, mirrored components, bilingual invoices and receipts, and a real Arabic speaker reading every screen out loud before launch.
Notice what is absent. No rewrite. In most cases the generated code is a perfectly reasonable starting skeleton, and the honest job is to harden it rather than to feel superior to it.
The view from the delivery side in 2026
Something has genuinely changed this year, and it is worth saying plainly. The bottleneck in Gulf startups has moved. It used to be building the thing. Now it is trusting the thing — the bank's risk team, the enterprise buyer's security questionnaire, the regulator's residency question.
The counterargument deserves credit, and I hear it from good founders: hiring a senior engineering team in Dubai to harden a product that has not proven demand is a bad use of runway. That is true, and it is exactly why so many teams start with a builder tool. My disagreement is narrower than it sounds. The mistake is not starting on Lovable. The mistake is treating the day you get your first paying customer as a marketing milestone rather than an engineering deadline.
The ambition around us makes the deadline sharper. Dubai's D33 economic agenda, launched by the Dubai Government in January 2023, sets a ten-year target to double the emirate's economy — and the buyers created by that push are enterprises and government entities, not early adopters who forgive a broken refund.
Where a team like mine earns its place is inside that four-week window — engineers who have already integrated Tap and Moyasar, already argued with a settlement file, already shipped an Arabic checkout that a Saudi customer did not complain about. Unexciting experience. It is also the entire difference between a launch and a recovery.
So here is the question I would actually like you to answer, not to me but to your own team this week: if a bank's security reviewer opened your codebase tomorrow morning, which single file would you not want them to read first? Go and look at it. Then tell your team what you found — that conversation is worth more than another sprint of features.
Frequently asked questions
Can I use Lovable or Replit to build a production app in the UAE?
Yes, as a starting point. Both tools produce working application code quickly, and that code can reach production. What they cannot supply is regional context — local payment rails, Arabic layout, tenant isolation and data residency all need deliberate engineering afterwards, typically three to five weeks of focused work before a first paying customer.
Which payment gateway should a Saudi startup integrate first?
Choose the gateway that covers mada properly, since mada sits on effectively every Saudi debit card. Moyasar and Checkout.com are both used widely in the Kingdom, and Tap Payments is common across the wider GCC. Confirm settlement timing, refund behaviour and reconciliation file format before writing integration code, not after.
How long does it take to make an AI-generated app Arabic-ready?
Expect two to four weeks for a typical MVP. The work covers converting physical CSS to logical properties, mirroring components and icons, choosing a proper Arabic typeface, formatting numbers and dates correctly, and producing bilingual invoices. Translation itself is the smallest part of that effort.
