Most failed app projects do not fail technically. They fail at the point of disagreement: a late delivery, a feature the client says was agreed and the provider says was out of scope, or a refusal to hand over code when moving to another provider.
A good contract does not prevent disagreement, but it decides who bears its consequences. This guide explains the clauses that protect you, the wording to reject, and their order of importance.
Note: this is general guidance, not legal advice. Have your contract reviewed by a qualified lawyer before signing, particularly for large or cross-border projects.
First: critical clauses — do not sign without them
1. Source code ownership
The single most important clause. The contract must state explicitly that the source code, database, store accounts, and domain transfer in full to you upon completion of payment.
Wording to reject: "the provider grants the client a licence to use the software." A licence is not ownership. It means you rent your app and cannot modify it or move it to another provider without permission.
Also require: delivery of the code to a repository you own — GitHub or equivalent — (not the provider's account), plus deployment documentation and access credentials for external services.
2. A detailed scope of work
The scope must be a detailed annex, not a general paragraph. It covers: screens by name, features function by function, supported platforms and versions, external integrations, and what is explicitly out of scope.
The clause that prevents the most disputes: the "out of scope" list. Defining what will not be built matters more than listing what will.
3. A payment schedule tied to deliverables
Do not pay everything upfront, and do not pay by time. Tie each instalment to a verifiable deliverable:
| Milestone | Instalment |
|---|---|
| Contract signing | 20 – 30% |
| Design approval | 20% |
| Beta delivery | 25 – 30% |
| Final acceptance and release | 20 – 30% |
Hold back at least 20% for the final instalment after final acceptance. That instalment is your only leverage for finishing the last details.
4. Acceptance criteria
How do you agree the work is "complete"? Without written criteria, acceptance becomes a matter of opinion.
Require measurable criteria: the app runs on specified OS versions, passes an agreed test checklist, contains no defects classified "critical" or "high", and meets a defined response time. Also specify your testing window (two weeks, for example) and what happens if you do not respond within it.
Second: clauses that protect you from surprise costs
5. Change policy
Every project sees change requests. The contract must define:
- Free revision rounds per stage.
- What counts as a "revision" versus a "new feature" — the most important distinction in the whole contract.
- How out-of-scope changes are priced (a published hourly rate or a prior estimate).
- A requirement for written approval before any paid additional work begins.
Without this clause, you will either face a surprise invoice or a refusal to make a change you assumed was obvious.
6. Warranty and what it covers
The contract must distinguish between:
- Bug fixing — defects in what was delivered, which should be free during the warranty period (3–6 months is typical).
- Maintenance and development — new features or compatibility updates, which are paid.
Ask explicitly: does updating the app for a new iOS release fall under warranty or maintenance? The answer varies by provider, and agreeing upfront is cheaper than negotiating later.
7. Delay and remedies
What happens if delivery is late? A balanced contract includes:
- A commitment to a phased timeline with specific dates.
- An early notification mechanism when delay is anticipated.
- Compensation or a discount for substantial unjustified delay.
- And conversely: relief for the provider if the delay stems from your own lateness in supplying content or approvals — a fair clause you should accept.
Third: commonly overlooked clauses that cost a lot
Confidentiality and data protection. The provider's obligation to keep your data and your users' data confidential, comply with the applicable data protection law, and delete their copies after the project ends.
Third-party dependencies. Which external services the app relies on, who owns those accounts, and who bears their fees. Discovering that a critical service account is in the provider's name after the relationship ends is a real problem.
Team continuity. What if the lead developer leaves? Require a commitment to code documentation and structured knowledge handover.
Dispute resolution. Which law governs the contract, and which forum decides disputes. Critical in cross-border engagements — a contract without a clear jurisdiction clause makes any dispute slow and expensive.
Early termination. How does the engagement end if it does not work out? What is owed? Do you receive what was completed to date? Require the right to receive completed work in exchange for what you have paid.
Wording to reject
| Wording | Why reject it |
|---|---|
| "Licence to use" instead of ownership transfer | You rent your app rather than own it |
| 100% payment upfront | You lose all leverage |
| Scope as a general paragraph | Every later dispute resolves against you |
| "Delivery within a reasonable period" | "Reasonable" has no enforceable meaning |
| Domain registered in the provider's name | Deferred leverage against you |
| No termination clause | You are stuck in a failing relationship |
| Unlimited liability on you | Open-ended risk with no cap |
A quick pre-signing checklist
- ✅ Code, database, and store accounts are entirely mine on completion of payment.
- ✅ Domain registered in my name, not the provider's.
- ✅ Detailed scope annex, including an "out of scope" list.
- ✅ Payments tied to deliverables, with 20% held to the end.
- ✅ Written, measurable acceptance criteria.
- ✅ Clear change policy distinguishing "revision" from "new feature".
- ✅ Warranty with defined duration and coverage.
- ✅ A delay clause balanced for both parties.
- ✅ Confidentiality and data protection clause.
- ✅ Termination and dispute resolution with clear jurisdiction.
What happens when things go wrong
Most contract guides describe the ideal project. The clauses that matter most are the ones governing failure — and they are the ones least often read before signing.
If the vendor misses the deadline. A delivery date with no consequence attached is a preference, not a term. Define what happens: a penalty, a fee reduction, or a right to terminate after a defined grace period. Equally, be fair about delays you cause — a well-drafted clause pauses the clock when the client is late approving, which is the most common source of slippage.
If quality is unacceptable. "The work must be professional" is unenforceable because it is unmeasurable. Define acceptance criteria instead: the app runs on named OS versions, passes an agreed test list, and loads within a stated time. Acceptance testing should have a defined window — typically 14 days — after which delivery is deemed accepted.
If you want to stop. A termination clause protects both parties. It should state notice period, payment for work completed to date, and — critically — that you receive all work product regardless of the reason for termination. A contract permitting the vendor to withhold completed work on exit is one to refuse outright.
If the vendor disappears. This is the scenario nobody plans for and it happens. Your protection is structural rather than legal: require code to be pushed to your repository from day one, not delivered at the end. If the code lives only on the vendor's machines, a contract is a claim to something you cannot access.
If there is a dispute. Specify governing law and jurisdiction. For cross-border work — a Gulf client with a vendor elsewhere — this determines whether enforcement is realistic or theoretical. Arbitration is often faster than courts for technical disputes, but agree the venue in advance.
Warranty versus maintenance — not the same thing
These are routinely conflated, and the confusion produces genuine disputes after launch.
Warranty covers defects in work already paid for: something specified but not functioning correctly. It should be free, typically for 3 to 6 months, and it is not a favour — it is the vendor delivering what was contracted.
Maintenance covers new work: OS compatibility updates, new features, content changes, and ongoing monitoring. It is a separate paid engagement.
The dispute always arises at the boundary. Settle it in the contract with explicit examples:
| Scenario | Warranty | Maintenance |
|---|---|---|
| A specified feature does not work | ✅ | |
| Crash on a device that was in scope | ✅ | |
| App breaks after a new iOS release | ✅ | |
| You want an additional screen | ✅ | |
| Third-party service changes its API | ✅ (usually) | |
| Security flaw in delivered code | ✅ |
That last row is worth insisting on: a security vulnerability in code you paid for is a defect, not a change request.
For how to structure the ongoing side, see In-House Maintenance or a Contract?.
Related reading
- Freelancer or agency? — the four conditions that protect you.
- In-house maintenance or a contract? — what a maintenance contract must include.
- MVP or full product? — freezing scope before you start.
Frequently asked questions
Who owns the code after the project ends?
You should own it entirely — source code, database, store accounts, and domain — transferring on completion of payment. Beware "licence to use" wording, which is not ownership and means you cannot modify your app or move it to another provider without permission.
How much should I pay upfront?
Between 20% and 30% at signing, with the remainder tied to verifiable deliverables. Hold back at least 20% for the final instalment after final acceptance. Paying in full upfront removes all your leverage if delivery slips or quality disappoints.
What is the difference between warranty and maintenance?
Warranty covers fixing defects in what was delivered and is typically free for 3–6 months. Maintenance covers new features and compatibility updates for new OS releases, and is paid. Specify explicitly which category a compatibility update for a new iOS release falls into.
What if delivery is late?
A balanced contract specifies a phased timeline with dates, early notification when delay is anticipated, and compensation for substantial unjustified delay — with relief for the provider if the delay stems from your own lateness in supplying content or approvals. Avoid "within a reasonable period", which has no enforceable meaning.
Do I need a lawyer to review the contract?
For small projects, the checklist above covers most risks. For projects in the tens of thousands, cross-border engagements, or those handling sensitive data — yes, and review cost is trivial compared to the cost of a later dispute.
What is the most dangerous commonly overlooked clause?
Registering the domain and store accounts in the provider's name. It looks like an administrative detail, but it practically means you cannot move to another provider or even access your published app without their consent. Verify this before signing, not after.
Conclusion
A good contract does not signal distrust. It means both parties agreed the rules before they needed them.
The three clauses you never concede: full ownership of code and domain · a detailed scope including "out of scope" · payments tied to deliverables with 20% held back.
A provider who hesitates specifically on those three is telling you something important about how they work — listen to it.
Want a partner who starts with a clear scope and a fair contract? Get in touch for a free, no-obligation scope assessment. See our mobile app development services and our guide to choosing a development company.