Mobile App Development Contract Checklist for UAE Businesses

A mobile app development contract is the one document you will be glad you read slowly. Most disputes we hear about between clients and agencies do not start with bad code. They start with a sentence nobody wrote down: who owns the source code, what counts as "finished", what happens when the schedule slips, who pays for the changes that appear in week six. This mobile app development contract checklist for the UAE walks through every clause worth checking before you sign, in plain language.

One honest note first. We are software developers, not lawyers, and this is not legal advice. Use the checklist to arrive at your lawyer's office with the right questions, and have a qualified UAE lawyer review the final document. Rules differ between mainland, free zones such as DIFC and ADGM, and other emirates, and they change.

Why the contract matters more than the quote

The quote tells you what you will pay if everything goes to plan. The contract tells you what happens when it does not. Apps are built from many small decisions, and it is normal for some of them to change. The contract is where you agree, calmly and in advance, how those changes will be handled.

A good contract also protects the agency. When both sides know what was promised, there is less room for resentment. If a vendor resists writing things down, that is information about how the project will go.

Before you get to the contract, you will already have chosen a partner. If you are still comparing, read how to choose an app development company in the UAE, and prepare a requirements document so the contract has something solid to refer to.

The documents you may be asked to sign

Not every project uses all of these, but you will meet most of them:

• NDA (non-disclosure agreement). Signed early, before you share your idea in detail. Check that it is mutual and that it has an end date.
• Statement of work (SOW). The detailed description of what will be built, the timeline and the price. It may be a schedule attached to the main agreement.
• Master services agreement (MSA). The general legal terms: payment, liability, confidentiality, termination. Often used when you will work together on several projects.
• Service level agreement (SLA). Response and fix times for support after launch.
• Data processing terms. Needed when the agency will handle personal data of your customers.

If a vendor sends one short document that covers all of it in two pages, ask which parts are missing.

1. A scope you can point at

This is the single most important clause. A good scope lists:

• Platforms: iPhone, Android, web admin, or all three, and which minimum operating system versions.
• User roles: customer, provider, driver, admin, and what each can do.
• Features and screens written as a numbered list, so that item 14 is clearly in or out.
• Integrations: payment gateways, SMS, maps, email, analytics, CRM, each named.
• Languages: Arabic, English, and whether right-to-left layouts are included.
• What is excluded. Say it out loud: content writing, photography, marketing, app store listing text, third-party fees.

The exclusions matter because they are where surprise invoices come from. If something important is not in the list, ask whether it is included, and get the answer written down.

Attach wireframes or a clickable prototype to the contract as an appendix. Pictures settle arguments faster than paragraphs.

2. Payment tied to milestones

Avoid contracts that ask for most of the money up front, and avoid ones that bill only by the calendar. A typical, fair structure splits payment across stages that you can inspect:

1. A start payment to reserve the team and begin discovery.
2. Payment when designs are approved.
3. Payment at one or two development checkpoints, with a demo each time.
4. Payment when the testing build is delivered.
5. A final payment on acceptance and launch.

The exact percentages vary by agency and project size, so agree on them case by case rather than copying a rule of thumb. What matters is that each payment is attached to something you can see and approve.

Also check:

• The currency (AED or USD) and what happens if exchange rates move.
• Whether VAT is shown separately. UAE VAT is added on top of most quotes.
• The payment terms in days, and late payment fees.
• Third-party costs such as app store developer accounts, map APIs, SMS and hosting. These are usually billed to you directly or passed through at cost.

For a sense of typical budgets, our own indicative bands for one platform, before VAT, are around USD 5,400 to 7,200 for a basic app, USD 9,000 to 14,400 for a medium app, and USD 14,400 and up for an advanced one. See how much an app costs in Dubai for what drives these numbers.

3. A realistic timeline, and what happens when it slips

A date without a plan behind it is a hope. The contract should include a schedule with named phases: discovery, design, development, testing, launch. For a realistic range, read how long it takes to build an app in Dubai.

Then ask the awkward question: what if it slips? Delays have two sources and the contract should treat them differently.

• Agency delays (staffing, estimation errors, rework). The agency should bear these. Some contracts include a modest credit for repeated late milestones.
• Client delays (late feedback, missing content, changing decisions). The timeline should move by the same amount. Agree how many working days you have to review each deliverable. A silent client can pause a project, which is fair, but it should be written down.

Be wary of penalty clauses that look strong on paper but are never enforced. A clear process for flagging risk early is worth more than a financial penalty nobody wants to use.

4. Who owns what

Ownership is the clause that causes the most pain later. Spell out each item.

Source code

The standard position for a custom-built app is that, once you have paid in full, you own the source code you commissioned. Many contracts say ownership transfers on final payment. Check that wording carefully. Also check for any clause that lets the agency reuse your code for other clients; if they use shared components, those should be clearly separated and licensed to you.

Third-party and open-source components

Every app relies on libraries written by others. Ask for a list of the main ones and their licences. Most are permissive, but some licences carry conditions, and you do not want to find that out during due diligence for an investor.

Design files

Source design files (not only exported images) should be delivered to you. Check who owns the logo, icons, illustrations and any stock assets, and whether stock licences cover commercial use.

Accounts and credentials

The Apple Developer account, Google Play Console, domain name, cloud hosting, analytics and payment merchant accounts should be created in your company's name, with the agency added as a user. Do not let an agency publish your app under their account. If the relationship ends, taking an app back from another company's store account is slow and sometimes impossible without losing reviews and users.

Data

Your customers' data belongs to you. The contract should say the agency will not use it for anything other than delivering the service.

5. How changes are handled

Changes are not a sign of failure. They are what happens when you see your product working and realise it could be better. A change process keeps those good ideas from turning into arguments.

Agree on a simple routine:

1. You describe the change in writing.
2. The agency estimates the effect on cost and time.
3. You approve or decline in writing.
4. Only then does work begin.

Decide how small tweaks are treated. Some agencies include a limited number of revision rounds on designs; some include a small buffer of hours. Whatever the arrangement, write the numbers down. Also agree on hourly or daily rates for changes, so there are no surprises later.

A useful trick is to keep a shared "parking lot" list for ideas that are not in scope. Review it at the end of each milestone and decide what goes into the next phase.

6. Testing and acceptance

"Done" needs a definition. Without one, a project can drift into a never-ending fix list or, equally bad, be declared finished while you are still finding obvious problems.

• Acceptance criteria: the list of behaviours that must work for each feature to count as complete.
• Test environments: a staging version that mirrors production, so you can try the app before the public can.
• Review period: how many days you have to test and report issues after each delivery.
• Severity levels: what counts as critical (payments fail, app crashes), major, or minor, and which must be fixed before launch.
• Devices and operating systems the app will be tested on, by name.

Our mobile app development process guide shows where testing sits in a normal project. Ask to see a sample test report from a previous project so you know what good looks like.

7. Warranty, support and maintenance

Software has bugs, and some only appear with real users. Two different things are often mixed up, so separate them in the contract.

• Warranty (bug-fix period). A period after launch, commonly a number of weeks or a few months, when the agency fixes defects in the agreed scope at no extra charge. Check when it starts: on launch or on acceptance.
• Ongoing maintenance. Updates for new phone versions, library upgrades, security patches, monitoring and small improvements. This is a separate paid service. Annual maintenance commonly runs somewhere around 15 to 20 percent of the build cost, depending on complexity. Our guide to maintenance costs in the UAE explains what is covered.

If you want a support agreement, define response times by severity. A payment outage and a typo should not wait in the same queue.

8. Confidentiality and data protection

Your app will probably hold personal data about customers, and in some sectors, sensitive data. The contract should cover:

• A confidentiality clause that survives the end of the project.
• Where data will be stored and whether it leaves the country.
• Who at the agency can access production data, and how that access is logged.
• What the agency does if there is a data incident, and how fast they must tell you.
• Deletion of your data and test copies when the project ends.

UAE federal data protection law and some sector regulations (for example in healthcare and financial services) add obligations. Your lawyer will advise on what applies. For the technical side, see mobile app security and data protection in the UAE.

9. Liability, indemnity and insurance

These clauses are boring until they are not. Check:

• Limit of liability. Many agencies cap their liability at the fees paid. That is common, but you should know the number.
• Intellectual property indemnity. The agency should stand behind the claim that the work does not infringe someone else's rights.
• Exclusions. Clauses that exclude "indirect" losses, such as lost profit, are usual. Understand what they mean for your business.
• Insurance. For larger projects, ask whether the agency carries professional indemnity cover.

Do not try to negotiate every line. Focus on the points that would hurt most if they went wrong.

10. Termination and exit

Hope for a long, happy partnership, and plan for the other outcome. A fair exit clause covers:

• Notice periods for each side.
• What happens to work in progress and to payments already made.
• Delivery of all code, designs and documentation up to the point of exit.
• Help with transition to a new team, billed at agreed rates.
• Return or deletion of confidential information.

An agency that agrees to a clear exit is usually confident about the relationship. One that refuses to discuss it deserves a second look.

11. Governing law and dispute resolution

Most contracts name the law that applies and where disputes will be heard: the UAE courts, a free-zone court, or arbitration. Arbitration can be quicker and more private but has its own costs. For cross-border projects, make sure both sides understand which law governs. This is firmly a topic for your lawyer, but you should at least know what the contract says, and agree on a first step such as a meeting between senior people before anything formal.

12. Clauses specific to apps

Beyond the usual software terms, check these app-specific points:

• App store compliance. Who is responsible if Apple or Google rejects the app, and who resubmits? See our launch checklist.
• Platform changes. New iOS and Android versions can break features. Is adapting to them in warranty or maintenance?
• Third-party service changes. Maps, payments and SMS providers change pricing and APIs. Who monitors and pays?
• Analytics and tracking. Who sets up and owns the analytics accounts, and what personal data is collected?
• Localisation. Whether Arabic text and right-to-left layout are included and who provides translations. Read Arabic app localisation and RTL for UAE apps.
• Performance expectations. Target load times and the number of users the system should handle at launch.

Fixed price, time and materials, or dedicated team?

The pricing model shapes the contract more than any other choice, so understand it before you read the legal text.

Fixed price

The agency quotes one price for a defined scope. It suits projects whose requirements are clear and stable. The risk for you is that any change becomes a negotiation; the risk for the agency is underestimating, which can tempt corners to be cut. The scope clause carries all the weight here, so be strict about it.

Time and materials

You pay for the hours worked at agreed rates, usually with an estimate and a cap. It suits projects where requirements will change as you learn. You get flexibility, but you need good reporting: weekly summaries of hours and progress, and a rule that the estimate cannot be exceeded without your written approval.

Dedicated team

You rent a team (developers, a designer, a tester) for a monthly fee and direct their work. It suits long-running products with a steady roadmap. Your contract should say who is on the team, how replacements are handled, and how much notice is needed to scale up or down.

Many projects blend these: a fixed-price discovery phase, then a fixed-price first release, then a monthly retainer. If a vendor proposes this, make sure each phase has its own scope and acceptance criteria.

Source: Arka Softwares delivery process.

What a milestone table can look like

Here is a simple, illustrative layout. The stages and percentages are examples to show the structure; agree your own with the agency.

Milestone	What you receive	How you approve it
Discovery complete	Requirements, user flows, wireframes	Written sign-off on the scope document
Design approved	Visual designs for all screens, Arabic and English	Sign-off after a review meeting
First working build	Core features running on a test build	Demo and test on your own phone
Feature complete	All agreed features, admin panel	Walk through the acceptance list
Launch ready	Tested build, store listing, documentation	Acceptance sign-off and handover

The right-hand column is the one that matters. A payment linked to "when the agency says it is finished" is weaker than one linked to a demo you can run on your own phone.

Plain-language clause examples

You do not need to draft legal text, but it helps to recognise what a good clause says. The examples below are simplified descriptions, not wording to copy.

• Ownership: "On receipt of full payment, all rights in the custom code and designs created for this project transfer to the client. The agency keeps rights to its general tools and libraries and grants the client a lasting licence to use them within the app."
• Changes: "Any change to the agreed scope must be requested in writing, estimated by the agency and approved by the client before work begins."
• Acceptance: "The client has ten working days to test each delivery. Defects found in that period will be fixed by the agency at no extra charge. If the client does not respond, the delivery is deemed accepted after a reminder."
• Warranty: "For ninety days after launch, the agency will fix defects in the agreed features free of charge."
• Exit: "On termination, the agency will deliver all work completed to date, including source code and documentation, within seven days of the final undisputed payment."

Notice the shape: each clause names who does what, by when, and what happens if they do not. Vague promises tend to be the ones that cause arguments.

Running the project after you sign

A contract does not run the project. Good habits do. Agree on these in the first week:

• One contact on each side who can make decisions. Ten people sending feedback to the developers slows everything.
• A regular meeting, weekly for most projects, with a short written summary afterwards.
• A shared place for decisions. A simple shared document or board where approvals and changes are recorded.
• Access to a test build from early on, not just at the end. Seeing the app on your phone every couple of weeks removes most of the nasty surprises.
• A risk list. Ask the agency to flag anything that could affect time, cost or quality, and review it together.

Treat the agency as a partner. The best projects we see are the ones where the client answers questions quickly and the agency raises problems early.

Handling disagreements without losing the project

Even good projects have disagreements. A few habits keep them small:

1. Raise the issue as soon as you spot it, in writing, with a specific example.
2. Check the contract and the scope document together before assuming bad faith. Many disagreements turn out to be a gap in the wording.
3. Escalate to senior people on both sides if the project team cannot settle it in a few days.
4. Keep paying undisputed amounts and keep the work moving while you resolve the disputed one, if the contract allows it.
5. Use the formal route in the contract only as a last resort.

Special situations

Startups with little budget

Ask for a smaller first release with a clear scope, then expand. Make sure the contract allows additional phases at agreed rates, so you are not locked into the first price forever. Also be cautious about paying with equity unless you have separate legal advice, because it complicates ownership.

Government and semi-government clients

Procurement rules are often stricter and may require specific templates, local presence or security reviews. Allow extra time and make sure the contract reflects those requirements.

Projects with sensitive data

Healthcare, finance and education projects may require data to stay in particular locations and need extra security testing. Add these as explicit requirements, not assumptions.

Working with an overseas team

Time differences, tax treatment and the governing law all matter. Check how invoices are issued, how VAT applies, and which courts or arbitration would handle a dispute. A local legal entity and an office you can visit can make life easier.

Red flags in a contract or a conversation

• A very low quote with no detailed scope.
• No written mention of source code ownership.
• The agency wants to register accounts in its own name.
• Most of the payment is due before you have seen anything.
• No defined acceptance process, only a promise to "make you happy".
• Refusal to name the people who will work on your project.
• No mention of warranty or support.
• Pressure to sign quickly because "the price expires".

Any one of these can be explained. Several together suggest you should keep looking.

Questions to ask before you sign

1. Can you walk me through the scope and tell me what is not included?
2. When exactly does the source code become mine?
3. Who owns the Apple and Google accounts?
4. How do you price and approve changes?
5. What does your warranty cover, and for how long?
6. Who will work on my project, and are they employees or subcontractors?
7. What happens to my project if a key person leaves your company?
8. Can I speak to a past client with a similar project?
9. How do you handle our data, and where is it stored?
10. What is the process if either of us wants to end the contract?

A pre-signature checklist you can copy

• Scope list and wireframes attached to the contract.
• Platforms, languages and integrations named.
• Milestones, amounts and due dates in a table.
• VAT and third-party costs shown separately.
• Timeline with phases and a process for delays.
• Ownership of code, designs, accounts and data written clearly.
• Change request process and rates.
• Acceptance criteria and test environments.
• Warranty period and maintenance terms.
• Confidentiality, data protection and incident handling.
• Liability limits and IP indemnity.
• Termination, handover and dispute resolution.
• Lawyer review completed.

Common questions about app contracts

Should I sign before or after the discovery phase?

Many agencies offer a short paid discovery phase under a small agreement, and then a full contract once the scope is clear. This is often a sensible way to reduce risk on both sides, because the larger price is based on a properly understood scope instead of a guess.

Can I use a template from the internet?

A template can be a starting point for your checklist, but not a substitute for legal review. Templates are rarely written for UAE law, and they do not know your project.

Is it normal for the agency to keep reusable components?

Yes. Agencies build up libraries of common building blocks such as login screens or payment handling. This is fine as long as the contract gives you a lasting right to use them in your app and does not stop you from working with another team later.

What if I want to change the platform halfway?

Treat it as a scope change. It will affect cost and schedule, and the change process should handle it like any other. If you are unsure about the platform at the start, settle that first; our article on native, cross-platform or PWA can help.

Do I need a separate contract for the design?

Not necessarily, but design should be its own milestone with its own approval. Some clients pay for design separately and then take the designs to another developer, which is possible if the contract delivers the source design files.

Who pays for the app store accounts?

You do, under your own company name. The agency should guide you through the setup but not hold the accounts on your behalf.

How long should a contract review take?

Allow a week or two for review and negotiation, longer for large or regulated projects. Rushing is the most common reason people sign terms they later regret.

Your plan for the two weeks before signing

1. Days 1 to 3: finalise your requirements document and share it with your shortlisted vendors for quotes on the same scope.
2. Days 4 to 6: compare quotes line by line. Ask each vendor about the differences. Speak to a past client.
3. Days 7 to 9: choose a vendor and request the draft contract and statement of work.
4. Days 10 to 12: review the draft with this checklist, mark questions, and send them to the vendor. Send it to your lawyer in parallel.
5. Days 13 and 14: agree on changes, confirm the final scope and milestones, and sign.

It may look slow, but two weeks of care at the start is cheap compared with months of rework or a dispute later.

Where this fits in the bigger picture

A contract is one step in a longer journey. Before it, you decide whether to build native, cross-platform or a PWA, and what the full app development journey in the UAE looks like. After it, the contract gives you a framework for a calm, predictable project.

If you would like to see how we write our own scopes and milestones, talk to our team through our mobile app development service page. We are happy to walk through a draft with you, whether or not you end up working with us, and to point out the clauses we would ask any vendor about.