UK app development contracts: what to put in your SOW and MSA

October 31st, 2026 at 10:09 am

By Ronak Shah, Nordstone | Last updated: October 2026

An MSA sets the rules for the whole relationship, while a SOW describes one project: scope, deliverables, milestones, price and acceptance criteria. Put payment terms, ownership, liability and termination in the MSA, and everything specific to the build in the SOW. Your contract should also say which document wins if they disagree.

TL;DR

• MSA and SOW: an MSA sets the broad terms for the relationship, while a SOW sets out one project’s terms and relies on the MSA’s legal terms, as HCR Law explains.
• Acceptance: write the acceptance procedure, repeat testing and a completion deadline into the contract, because acceptance can be deemed if you skip testing or use the software live, says Pinsent Masons (a guide written in 2008, so use it for principles, not current law).
• Changes: agree a change control procedure for suggesting, documenting, pricing and implementing variations, as the same 2008 guide recommends.
• Quality: in England, Wales and Northern Ireland a business supplier must carry out a service with reasonable care and skill under section 13 of the Supply of Goods and Services Act 1982; Scottish contracts differ.
• Liability caps: liability for death or personal injury caused by negligence, and for fraud, cannot be excluded in England and Wales, and other limits must be reasonable, according to Lewis Silkin and CMS.
• Payment: tie each payment to an accepted milestone. Late-payment interest of 8% above base rate is current law, but a Commercial Payments Bill would make it mandatory.

What is the difference between an MSA and a SOW?

A master services agreement, or MSA, is the umbrella contract. HCR Law describes it as outlining the broad terms that govern the relationship between the parties, covering matters such as payment timing, termination, confidentiality and intellectual property. A statement of work, or SOW, sets out the specific services or project-level terms and relies on the MSA for the general legal terms.

In practice, that means you negotiate the legal terms once and add a new SOW for each phase: perhaps discovery and design, then the MVP build, then support. It saves renegotiating the same clauses every time, and it keeps the legal detail apart from the delivery detail that your product team actually needs to read.

Image 1: one MSA covers the relationship, and each SOW covers a piece of work.

One point is easy to miss. The sources describe how the two documents fit together, but not which one prevails if they conflict, so that depends on the wording. Ask for an order-of-precedence clause that says which document wins, and whether a SOW can override a named MSA term. A short project can use a single contract that combines both, but the same sections should still be there.

What should go in your MSA?

The MSA holds everything that does not change from project to project. Start with payment: invoice timing, payment period and what happens when either side pays late. Then ownership. Our guide on who owns the code explains why a written assignment of code and designs matters, and when it takes effect. Add confidentiality. If the agency will handle your users’ personal data, UK GDPR requires a written contract with it as your processor, and the ICO says that contract must require the processor to delete or return the data at your choice when the services end.

Next come liability and warranties, covered below, and termination. Look for the right to end the contract for serious breach, and for what happens to your code, accounts and data when it ends, because a failed relationship is the wrong moment to discover you cannot get them. Our guide on what happens if your agency goes out of business explains why. Finally, check how disputes are handled: who you speak to first, and what happens if that does not work. A sensible clause escalates from the project leads to senior managers, then to mediation, before any court claim. Pinsent Masons reports that English courts can stay proceedings so parties can try non-court resolution, and may compel mediation where a judge thinks it appropriate, so it is worth building in from the start. Lastly, name the governing law and the courts. Contracts for England and Wales usually say so, and a Scottish supplier or customer may mean Scots law applies instead.

What should go in your SOW?

The SOW is where the project lives. It should be specific enough that a stranger could read it and tell whether a milestone has been delivered. The table below lists the sections to include and why each matters.

Scope is the section that causes most trouble. List features, screens, integrations and platforms, and state plainly what is not included, because anything unwritten becomes a change request. Our app development brief template helps you capture this before the SOW is drafted, and our guide to briefing a design-only or MVP-only project covers the narrower cases.

An illustrative milestone table (example figures, not a Nordstone quote)

How do you write acceptance criteria for an app?

Acceptance criteria turn “is it finished?” from an opinion into a test. Pinsent Masons advises that the contract should set out the acceptance procedure, allow for repeat testing and fix a completion deadline. Its guide dates from 2008, but the principle has not changed: if the customer does not test properly, or uses the software operationally, acceptance can be deemed to have happened, so that the supplier can be paid.

That cuts both ways. Write criteria you can actually test: the devices and operating system versions supported, performance targets such as load time, and how defects are graded, for example blocking, major and minor. If accessibility matters, name the standard. The W3C’s WCAG 2.2 is the usual reference. Then say how long you have to test, how you report defects and how long the agency has to fix them.

Image 2: a sensible acceptance process from delivery to payment.

Put the testing window in the diary when the milestone is due, and name who on your side signs off. Missing the window because nobody was watching is the most common way customers lose their right to complain.

How should milestones and payments be structured?

Tie each payment to accepted work, not to dates on the calendar. A typical structure pays a modest amount on signing and then releases further payments as milestones are accepted, with a final payment held until launch. The exact split is a commercial decision, and agencies will want enough cash flow to carry the work, so expect a conversation.

Be clear about the pricing model too. Pinsent Masons observes that fixed prices make variations costly, while time-based charging with a cap is common for changing requirements. Our UK app development cost guide shows typical budgets, and our list of hidden costs of app development covers lines that rarely appear in a quote, such as hosting and store fees. Check what the SOW says about expenses, third-party licences and who pays for them.

Payment terms also work in the agency’s favour if you pay late. The Late Payment of Commercial Debts (Interest) Act 1998 is still current law: unless the contract sets a substantial remedy, statutory interest of 8% above the Bank of England base rate applies. That is changing. A Commercial Payments Bill introduced in May 2026 would make that interest mandatory and cap payment terms at 60 days, with a lead-in period before the powers start, according to GOV.UK. It is not yet law, so check its progress and read your payment clause with both in mind.

How do you handle changes to the scope?

Changes are normal. Apps change once people see them, and a contract that pretends otherwise creates arguments. Pinsent Masons recommends a change control procedure to facilitate suggesting, documenting, pricing and implementing variations. In plain terms: any change is requested in writing, the agency says what it does to price and dates, and nothing proceeds until you both approve.

Ask how small changes are handled, too. A common sticking point is the grey area between a bug and a new feature. Your acceptance criteria are the referee: if the behaviour is in the criteria and does not work, it is a defect to fix at no extra charge. If it was never written down, it is a change.

Which liability and warranty terms should you check?

Start with the baseline the law gives you. Under section 13 of the Supply of Goods and Services Act 1982, where a supplier acts in the course of a business there is an implied term that it will carry out the service with reasonable care and skill. That Act applies in England, Wales and Northern Ireland but not Scotland, where the position differs, so a Scottish contract needs Scottish advice. That is a useful floor, but it is not a guarantee that the app will do what you hoped, which is why your SOW needs specific criteria.

Then look at the liability clause. Agencies often cap their liability, frequently by reference to the fees. Lewis Silkin explains that under the Unfair Contract Terms Act 1977 liability for death or personal injury caused by negligence cannot be excluded, and CMS adds that a party cannot exclude liability for its own fraud, and that other limits generally must be reasonable, with courts considering factors such as bargaining power and access to insurance. Ask what the cap is, what is excluded and whether the agency carries professional indemnity insurance. Also ask for a warranty period after launch in which defects are fixed without charge, and what it covers.

How can termination and handover protect you?

A good contract plans for the end. Look for the right to terminate for serious breach, for insolvency and, if you can negotiate it, for convenience on reasonable notice. Check what you owe on termination: usually the work done up to that point, and sometimes a notice period.

Then the handover. The contract should require the agency to hand over the code, designs, documentation and any accounts or credentials it holds, within a set time. Our list of questions to ask an agency before signing includes the exit questions that are easy to forget when everyone is optimistic.

Do you need a solicitor to review the contract?

For anything involving real money, yes. A solicitor can spot clauses that are unusual, one-sided or missing, and can tell you which are worth negotiating. Nordstone is an app development company, not a law firm, and nothing here is legal advice. Use this guide to know what to ask for, and have someone qualified check what you sign.

Frequently asked questions

Want a second opinion on a proposal or contract?

If you have a proposal or SOW in hand and want to know whether the scope, milestones and acceptance criteria hold up, send it over and we will tell you what is missing. Start with our app development brief template or get in touch with Nordstone.