What to Know Before Hiring a Developer in Dubai — A Founder's Checklist

This guide is not about finding a developer. You've already done that part. You have a name, maybe two, and you're trying to figure out whether to trust them with your project.

That is a completely different problem — and most hiring guides don't help with it. They're written for recruiters or HR departments, not for a founder who is about to hand over six months of savings and a product idea to someone they met on LinkedIn three weeks ago.

What follows is a checklist written from the developer side of the table. I know what good developers carry into a first call. I know what bad ones say to get past it. And I know what founders skip that they later wish they hadn't.

One note before we start: if you haven't settled the freelancer vs. agency question yet, that comparison is here. This guide assumes you have a candidate in front of you and want to vet them properly.

Know What You're Building Before You Talk to Anyone

This sounds obvious. It isn't.

I've been on dozens of first calls where the founder couldn't tell me what the product does in one sentence. Not because the idea was unclear — but because they had never been forced to compress it. And because they couldn't articulate it, they couldn't evaluate whether the developer understood it correctly, or whether the quote they received was for the right thing.

Before any conversation, write down:

• What the product does — one sentence, no jargon
• Who uses it — one persona, not "everyone"
• The one thing it must do at launch — this is your MVP scope
• What success looks like at 90 days — a number, not a feeling
• What you will not build yet — this list matters as much as the feature list

You don't need a product requirements document. You need enough clarity that when a developer gives you a quote and a timeline, you can tell whether they've understood what you asked for — or whether they've quoted something smaller (or larger) than what you actually need.

Founders who skip this step end up in scope disputes three months in. Paying for a renegotiation that a one-page brief would have prevented.

Read the Portfolio — Even If You Can't Read Code

You cannot evaluate code quality without technical training. But you absolutely can evaluate whether a developer's portfolio is credible, and that tells you more than most founders realise.

Completion. Are the projects actually launched, or are they all "in progress" or "under NDA"? A senior developer with several years of experience should have at least two or three live products they can point to. Not necessarily famous ones — but shipped, real, publicly accessible.

Relevance. A portfolio of e-commerce sites doesn't tell you much about their ability to build a SaaS dashboard with complex state management. Ask directly: "Have you built something similar to what I'm describing? What was the closest thing?"

Recency. Technologies move fast. A portfolio heavy on projects from 2018–2020 raises questions about what they've been doing since. Ask.

Ownership of the work. Ask which parts they personally built versus what a team handled. A developer who says "I built the whole thing" on a complex product either had very long timelines or is stretching the truth — either is worth clarifying.

Their name on it. Google the projects. Are they mentioned anywhere — a case study, a GitHub commit, a product launch post? A credible developer leaves digital footprints.

None of this requires you to read code. It requires you to ask the right questions about what you're looking at.

Verify References — With the Right Questions

Most people ask for references and then ask soft questions. "Was he professional? Would you work with him again?" Those questions get polished, unhelpful answers.

These get real information:

• "What was the hardest part of working with him — and how did he handle it?"
• "Was the project delivered on the timeline he quoted, or did it run over? By how much?"
• "Were there features that ended up costing more than the initial estimate? What happened?"
• "If you were starting that project today, would you give him a different brief?"
• "Is there anything you wish you'd asked him before you started?"

The reference's hesitation before answering tells you as much as the answer itself. Someone who worked well with a developer responds quickly and with specifics. Someone who had a difficult experience tends to get diplomatic and vague.

Also: ask if you can speak with someone they did not list as a reference. "Is there anyone else who worked closely with you on a project who I could speak to?" A developer who has worked here for a few years will have a network. Someone who deflects this question consistently may be managing what you hear.

Ask These Questions in the First Call

This is the section most non-technical founders get wrong. They ask technical questions they can't evaluate ("What's your stack?") and skip the questions that would actually protect them.

Here are the seven questions worth asking in the first conversation — with what a good answer looks like versus what should make you pause.

1. "Walk me through a project that went sideways. What happened and what did you do?" Good answer: specific, honest, names their own mistake or a miscommunication they should have caught earlier, explains the fix. Red flag: "All my projects go smoothly" or a story where every problem was the client's fault.

2. "How do you handle a situation where the client asks for a feature that will delay the project?" Good answer: explains how they log the request, discuss the trade-off with the client, and update the scope document before building anything. Red flag: "I just add it in" (no process) or "I always say no" (no flexibility).

3. "What do you need from me to stay unblocked?" Good answer: a clear list — access credentials, feedback turnaround time, design decisions by X date. They've thought about this because they've been blocked before and learned from it. Red flag: "Don't worry, I'll figure it out." That means they'll disappear for three weeks and you won't know why.

4. "How do you structure payments on a project like this?" Good answer: milestone-based, tied to deliverables. Upfront deposit (20–30%) to cover early work, then payments at defined checkpoints. Red flag: full payment upfront, or a vague "we'll sort it out as we go." Both transfer all the risk to you.

5. "Who owns the code when the project is done?" Good answer: "You do. We'll put that in the contract." Said without hesitation. Red flag: any hedging, any mention of licensing your own product back to you, or a confused look that suggests they haven't thought about it. This is a dealbreaker on any developer contract — see the contract section below.

6. "What happens if we need to stop the project halfway through?" Good answer: they can describe what a kill clause looks like — you pay for work completed, they deliver what's been built to date, and you part cleanly. Red flag: no clear answer, or a stance that you'd owe the full project cost regardless.

7. "Have you worked with UAE-based businesses before? Any Dubai-specific things I should know?" Good answer: mentions local payment gateways, Arabic UI requirements if relevant, or UAE App Store account requirements — anything that shows local market awareness. Red flag: "Development is the same everywhere." It isn't. See the Dubai-specific section below.

If you're currently vetting developers and want a second opinion on what you're hearing, feel free to run the conversation past me. I'll give you an honest read on whether the answers you're getting are what they should be — no pitch, no proposal deck.

Understand the Contract Before You Sign It

Most developers in Dubai will not hand you a predatory contract. But many will hand you an incomplete one — and that is almost as dangerous, because it leaves the most important questions unanswered and you won't know until there's a dispute.

These four clauses are non-negotiable. If they are missing, add them before you sign.

IP Assignment The contract must state explicitly that all intellectual property created during the project — code, design assets, database schemas, documentation — transfers to you upon final payment. Without this clause, the developer may retain rights to what they built. In the UAE, copyright in a work-for-hire arrangement does not automatically transfer to the client the way it might in other jurisdictions. Put it in writing. IP ownership is not a technicality — it determines whether you can sell your company, raise investment, or transfer the product to another developer.

Milestone Payment Structure Never pay the full software development cost upfront. A standard developer contract structure: 25–30% at project kickoff, 30–40% at a defined mid-project milestone (working prototype, backend complete, or similar), and the final 30–40% on delivery and acceptance. Each payment should be tied to a specific, testable deliverable — not a date.

Kill Clause (Early Termination) If the project needs to stop — for any reason, including budget, pivot, or performance — this clause defines what happens. You should pay only for work completed to that point, and the developer should hand over all work-in-progress code and assets. Anything other than this arrangement transfers unreasonable risk to you. A developer who won't include a kill clause is telling you something.

NDA / Confidentiality If you're sharing a product idea, business model, customer data, or proprietary processes, require a non-disclosure agreement before the first detailed conversation. Most professional developers sign these routinely. Anyone who refuses, or says "I've never had to sign one of those before" — and they've been working with businesses for years — is a yellow flag.

Run a Paid Trial Before the Full Project

This is the single most underused vetting tool available to non-technical founders — and the most reliable one.

Before you commit to a $30,000 build, pay $500–$2,000 for a scoped trial task. It should be a real piece of work from the actual project: a working authentication module, a data model for your core feature, or a design mockup of the main screen. Not a test exercise — something you'll actually use if it's done well.

You'll learn things no interview can tell you. How they communicate when they hit something they didn't anticipate. Whether their timeline estimates hold on a small scope before you bet the big budget on them. Whether the code quality matches what they described — if you can't evaluate it yourself, get a second developer to review the output. And how they handle handoff: do they document what they built, or do they drop a zip file and disappear?

Most professional developers will accept paid trial work. Some will credit the cost toward the full project. A developer who refuses a trial entirely — especially without a good reason — is worth being cautious about.

Red Flags That Should Make You Walk Away

Pressure to sign before you've reviewed the contract. Any legitimate developer gives you time to read what you're signing. Urgency here is manufactured.

Rates dramatically below market. Dubai senior developer rates in 2026 run AED 150–350/hour for quality freelancers. Anything at AED 50–80/hour warrants hard questions — not because cheap is always bad, but because that gap is too large to explain with "they're efficient."

No portfolio or portfolio that can't be verified. "All my work is under NDA" is occasionally true. It's also the default cover story for a thin track record. If they can't show you a single live project, ask why.

Vague scope agreement. If they quote you a project without asking detailed questions first, they've guessed at the scope. You'll see the difference later — in change requests, in "that wasn't included," in invoices for work you thought was already covered.

Unclear IP ownership. Even a small hesitation here should raise your concern. This should be an immediate, confident answer on any developer contract.

"I work with a team" without naming the team. Are these actual colleagues, or other freelancers they subcontract without telling you? Ask who specifically will touch your code. If they can't answer that, you don't know what you're buying.

A timeline that contradicts the scope. A full-featured mobile app in three weeks is not a skilled developer working fast. It's either a lie or an MVP so stripped down it won't meet your needs. I've seen founders sign off on a "three-week build" and receive a prototype with no backend, no auth, and a payment integration that didn't work.

Communication delays during the vetting stage itself. If they take four days to respond to your messages before you've even signed a contract, that is the best version of their communication you will see.

Dubai-Specific Things Most Guides Miss

Generic hiring guides — the ones written for a US or UK audience — skip the local factors entirely. Here's what actually matters if you're building for a UAE-facing product.

Personal Data Protection Law (PDPL) The UAE's PDPL came into force in 2022 and applies to any product that processes personal data of UAE residents. If your product collects names, emails, phone numbers, or any usage data, your developer needs to build with PDPL compliance in mind from the start — not as a retrofit after launch. Ask specifically whether they're familiar with the law and what data architecture decisions it affects. "I'll add a cookie banner" is not the right answer.

Arabic UI and RTL Support In the UAE, Arabic language support is a question of when, not if. Right-to-left layout needs to be factored into the architecture before a line of code is written — not bolted on afterwards. Retrofitting RTL into a codebase that wasn't designed for it is expensive and creates inconsistencies that are genuinely hard to fully resolve. A developer who says "we can add Arabic later" without having done it before may not understand how much work "later" actually involves.

UAE App Store Requirements Publishing on the Apple App Store and Google Play in the UAE requires a valid UAE developer account. Certain app categories — fintech, healthcare, anything adjacent to financial services — require pre-approval from relevant UAE regulators before you can list. If your developer has never shipped an app specifically for the UAE market, they may not know this until you're blocked at submission. That is an unpleasant place to discover it.

Local Payment Gateway Integration Stripe is not available directly in the UAE for businesses without a non-UAE entity. Your developer should be familiar with the alternatives that actually work here: PayTabs, Telr, HyperPay, Checkout.com (requires a UAE account), and Tap Payments for some use cases. If they propose Stripe as the payment solution for a UAE-based product without flagging this, they haven't shipped a real payments product in this market.

The Checklist — Save This Before Your Next Developer Call

Use this before you sign anything. If you find this useful, bookmark this page or share it with your co-founder — it covers ground that most founders only wish they'd checked before the dispute, not after.

Before the first meeting

1. Can I describe the product in one sentence?
2. Do I have a defined MVP scope (even a rough one)?
3. Have I reviewed their portfolio for live, verifiable projects?
4. Have I prepared the seven first-call questions above?

On the call 5. Did they ask me detailed questions about the project before quoting? 6. Did they answer the IP ownership question without hesitation? 7. Did they describe a clear milestone payment structure? 8. Did they explain what happens if the project is cancelled? 9. Did they flag any Dubai-specific considerations relevant to my product?

Reference check 10. Have I spoken to at least one (ideally two) previous clients? 11. Did I ask the hard questions — timeline accuracy, scope creep, how problems were handled? 12. Did anything about their references feel evasive or over-polished?

Contract review 13. Is IP assignment explicitly stated in writing? 14. Are payments tied to milestones with defined deliverables? 15. Is there a kill clause for early termination? 16. Is there an NDA if I'm sharing proprietary information?

Before the full commitment 17. Have I run a paid trial task? 18. Was the trial delivered on time, with clear communication? 19. Did someone technical review the trial output if I can't evaluate it myself?

If you can check every one of these, you've done more due diligence than most founders who eventually end up in a dispute with their developer. The ones who skip the checklist are usually the ones who need a lawyer six months later.

---

FAQ

How much does it cost to hire a developer in Dubai?

Senior freelance developers in Dubai typically charge AED 150–350 per hour in 2026, depending on specialisation and experience. For project-based work, a functional MVP runs AED 40,000–120,000 depending on scope. Agencies charge 30–60% more for equivalent work, covering their overhead and account management. For a detailed breakdown by project type, see MVP development costs and mobile app development costs in Dubai.

How long does it take to build an app with a freelance developer in Dubai?

A well-scoped MVP with a single focused developer typically takes 8–16 weeks. Simple tools or internal dashboards can move faster — 4–8 weeks. Complex consumer apps with custom features, integrations, and Arabic language support take longer. Timeline estimates given before a detailed scope review are guesses. Treat any timeline quoted in the first conversation as provisional until the developer has read your brief in detail.

Do I need a contract with a freelance developer in Dubai?

Yes, and it needs to be a real one — not a verbal agreement or a single-sentence email. The UAE does enforce written contracts, and without one, disputes over IP ownership, payment obligations, and scope become much harder to resolve. At minimum, your developer contract should cover IP assignment, milestone payment structure, scope definition, and what happens if the project is cancelled. If the developer doesn't have a standard contract template, draft one yourself or use a UAE-qualified freelance contract template.

What is IP assignment and do I need it?

IP assignment is the clause in a development contract that transfers ownership of the code, design assets, and any intellectual property created during the project from the developer to you. Without it, the developer may retain rights to what they built — even after you've paid for it. In UAE law, copyright in commissioned work does not automatically transfer to the client without an explicit written assignment. You need this clause. It should be clear, comprehensive, and unconditional upon final payment.

How do I protect my app idea when sharing it with a developer?

An NDA is the practical starting point. Most professional developers sign them routinely; any hesitation is worth noting. But an NDA protects you legally after the fact — it doesn't prevent someone from misusing your idea, it gives you recourse if they do. The more durable protection is being further along before you share: have wireframes, a defined feature set, and ideally a prototype. The more concrete your idea is, the less value there is in stealing the concept, because execution is what matters, and that's where you are.

---

Most of the founders who end up in disputes with their developer did not hire a bad person. They hired a decent developer without a clear scope, a proper developer contract, or an IP assignment clause — and found out what that costs when something went wrong.

The process in this guide closes those gaps before the work starts. It takes a few extra hours at the beginning and saves weeks of misalignment on the other side.

If you are at the stage of evaluating a developer for your project and want a straight read on the quotes or the contract terms you have received, I'm available to talk through it. No sales process, no proposal deck — just a direct conversation about whether what you're looking at makes sense.