App Development Contract Checklist

An app development contract is rarely read closely until something goes wrong, and by then the wording is fixed. Most disputes between app clients and vendors are not about fraud. They are about ordinary questions the contract never answered: was this feature in scope, is this a bug or a change, who pays to fix a crash found after launch, and what happens to the code if you leave halfway.

This checklist goes clause by clause through what a good app development contract should say, with the weak wording to watch for. Confidentiality and ownership basics are covered on our app development NDA and IP protection page, so here the focus is on delivery, money and exit. It is written from a delivery lead’s point of view, not a lawyer’s.

Cross-border app work usually sits in a small set of documents rather than one long agreement. Knowing which clause belongs where makes review faster.

• NDA. Signed before discovery, so you can share your idea, data model and plans safely. We sign the NDA before discovery as standard.
• Master services agreement (MSA). The legal terms that apply to all work: IP, confidentiality, liability, payment mechanics, termination, governing law.
• Statement of work (SOW). One per phase: scope, deliverables, milestones, team, price or rate, acceptance criteria. Discovery and build are often separate SOWs.
• Change orders. Signed amendments to an SOW when scope, time or price changes.
• Data processing agreement (DPA). GDPR Article 28 requires a binding contract when a processor handles personal data on your behalf, so you need one if GDPR or UK GDPR applies to your users. It is good practice elsewhere.

The advantage of this structure is that the MSA is negotiated once and each new phase only needs a short SOW. If a vendor offers one document covering everything, check that scope changes do not require renegotiating the legal terms.

The contract should assign all intellectual property created for your project to you: source code, designs, documentation, test scripts and build configuration. Any serious vendor should agree to that. The detail that changes outcomes is when assignment happens.

Assignment on creation, or on payment for each milestone, means you own what you have paid for at every point. Assignment “on completion” or “on final payment” means that if the project ends early, the code you funded may still belong to the vendor. Ask for the first. The guide to protecting your app idea and IP when outsourcing covers open-source licences and pre-existing vendor code in more depth.

Acceptance is where scope disputes become payment disputes. A useful clause has four parts.

• Criteria. Each feature has testable acceptance criteria in the backlog or requirements document that the SOW references. Our app requirements document template shows the format.
• Review window. You get a fixed number of business days to test each milestone build and accept it or report defects in writing. The number is agreed in the contract.
• Severity levels. Defects are classified, for example as blocking, major and minor. Blocking defects stop acceptance; minor ones go on a fix list and do not hold up payment.
• Deemed acceptance. If you neither accept nor report defects within the window, the milestone counts as accepted. Vendors need this to avoid indefinite delay; you need the window to be long enough to test properly.

Also state what acceptance is tested on: the agreed device and OS list, and a build installed from TestFlight or Play internal testing, not a demo on the developer’s machine.

Scope will change. A contract that pretends otherwise just moves the argument to the invoice. The clause should say that any change to agreed scope goes through a written change request with an impact note on effort, cost, timeline and risk, and that no work starts until you approve it.

Under fixed price, this is the main control on your budget. Under a dedicated team or time and material, the commercial impact is different, because you are buying capacity, but you still want changes to be visible and prioritised against the backlog. Our comparison of dedicated team vs fixed price explains how each model handles change.

One more line worth adding: who decides whether something is a defect or a change. The fair test is the written acceptance criteria. If the build does not meet them, it is a defect. If you want something the criteria never described, it is a change.

A warranty clause gives you a defined period after each release in which the vendor fixes defects against the acceptance criteria at no extra charge. The length is agreed in the contract. What matters more is the scope, so check that the clause says what is excluded:

• New OS versions and new store requirements released after acceptance
• Changes in third-party APIs and SDKs outside the vendor’s control
• Defects caused by changes made by you or another vendor
• Hosting outages on infrastructure the vendor does not manage

Those exclusions are reasonable, but they mean you need a plan for the work they leave out. Store rules change every year: Google Play, for example, requires new apps and updates to target Android 16 (API level 36) from 31 August 2026. That kind of work belongs in a maintenance or support agreement, not a warranty. Our app maintenance and support page covers what such an agreement includes.

Also decide who is responsible for store compliance in the build itself. Apple, for instance, has required since 30 June 2022 that apps which let users create an account also let them delete it from within the app. Make meeting current store guidelines at submission part of the vendor’s acceptance criteria.

Payment terms should follow the engagement model, not a generic template. In short: fixed price is paid by milestone after a one-to-two-week discovery, a dedicated team is billed monthly in advance, and time and material is billed monthly in arrears against a budget cap. The amounts and schedules are agreed in each contract. Our guide on how to pay software developers in Pakistan sets out each billing schedule and what you should hold before every payment, so this section covers only the contract wording.

• Invoice currency and route. Name both. If your vendor is in Pakistan, PayPal does not currently serve Pakistani businesses for receiving payments, so use bank wire or Payoneer.
• Payment window. A fixed number of days from a valid invoice, and what makes an invoice valid (milestone accepted, hours report attached).
• Transfer fees. Who pays sending and intermediary bank charges, so short payments do not become a monthly argument.
• Disputed invoices. You pay the undisputed part on time and raise the rest in writing with evidence. This keeps work moving while the disagreement is settled.
• Late payment. What the vendor may do, and after how much notice. Pausing work is a fair remedy; withholding your code or accounts is not.

Tax treatment of payments to a foreign supplier depends on your country, so ask your accountant before the first invoice.

You should be able to leave a vendor without losing your app. Three clauses make that possible.

Termination for convenience. Either side can end the contract with written notice, without proving fault. The notice period is agreed in the contract; a longer one usually makes sense for a larger team.

Termination for cause. A material breach, with a cure period in which the other side can fix it before termination takes effect.

Handover obligations. On any termination, the vendor delivers all code, documentation and credentials, confirms nothing is held outside your accounts, and provides transition support for an agreed period. You pay for accepted work and for work in progress at an agreed value.

If you ever need these clauses, our guide on how to switch app development companies mid-project walks through the handover in practice.

Limitation of liability. Vendors commonly cap liability, often linked to fees paid. That is normal. Check that the cap is mutual and that breaches of confidentiality, IP and data protection are treated separately. Your lawyer will have a view on what is reasonable in your jurisdiction.

Key personnel. If you chose a vendor because of a specific tech lead, name the role in the SOW, require notice before changes and describe how a replacement is onboarded.

Governing law and disputes. The contract has to name the law that applies and where disputes are heard. Common options in cross-border app work are England and Wales, a US state, the UAE (including the DIFC) or Pakistan, with arbitration as an alternative to courts. The NDA and IP page explains our position on governing law.