Field notes: the contract clauses every UK founder should negotiate

A founder forwarded me a development contract earlier this year and asked whether the day rate looked fair. The day rate was fine. What was not fine sat on page four, where the agency granted her a licence to use the software rather than transferring ownership of it. She would have paid six figures for permission to use her own product, and she would have found out at the point she tried to raise money or move to another team.

She is not careless. She is a serious operator who reads everything. But she read it the way most of us read contracts, checking the number and the timeline and assuming the rest is standard boilerplate. It is not standard. The app development contract clauses that decide how much power you have are the ones nobody highlights in the covering email, and almost all of them are negotiable if you ask before you sign rather than after.

I should say plainly that we build software and we are not solicitors, and anything with real money attached deserves a lawyer who does this for a living. What follows is what I have learned sitting on both sides of these documents, as the person selling the work and as the person buying it.

The app development contract clauses that matter most

If you read nothing else, these are the seven app development contract clauses to check before signing: intellectual property assignment on payment, ownership of the accounts and repository, a written definition of acceptance, a priced change control process, payment tied to milestones, a termination and handover clause, and a data processing agreement. Everything below is why each one earns its place.

None of these are exotic. They appear in most decent templates already, which is exactly why a contract that omits one is worth asking about.

One: ownership, not a licence

This is the clause that ends companies. There is an enormous difference between a contract that says you own the intellectual property in the software and one that says you are granted a licence to use it. Both can look reasonable in a fast read. Only one survives due diligence.

What you want is an assignment of all intellectual property rights in the deliverables to you, effective on payment. What you should watch for is a licence, a retained right for the agency to reuse the work, or silence, which usually favours the party that wrote the contract. Ask directly: on the day I have paid in full, do I own the source code, the designs, and the database schema outright. If the answer takes more than one sentence, keep reading.

Two carve-outs are legitimate and worth accepting. Agencies often retain ownership of genuinely generic internal tooling they reuse across clients, and open source components come with their own licences that nobody can assign. Both are fine as long as they are named, and as long as anything they retain is licensed to you perpetually so it cannot be withdrawn later.

Two: accounts and access in your name from day one

Ownership on paper means nothing if you cannot reach the thing you own. I have watched a handover stall for three weeks because the App Store account was registered to the agency, the cloud hosting was on the agency’s card, and the code lived in the agency’s private repository under a personal account.

Negotiate the opposite from the start. Your company owns the Apple Developer and Google Play accounts. Your company owns the cloud account and pays the bill directly. The code lives in a repository your company owns, and the agency has access to it rather than the other way around. This costs nothing to arrange in week one and is a small ordeal to unwind in month nine. It also tells you something useful about whoever is on the other side, because a good agency will already have suggested it.

Three: what “done” actually means

The most common cause of a project going wrong is not bad code. It is that both sides had different pictures of finished and neither wrote it down. So the acceptance clause matters more than it looks.

You want a definition of acceptance that references something concrete: an agreed scope document, a list of user journeys that must work, the devices and operating system versions supported, and a testing window with a stated length. You do not want acceptance to be automatic after a number of days of silence, which is a clause that quietly converts your inattention into agreement. And you want the defect handling to be explicit, meaning a warranty period after acceptance during which faults in the delivered work are fixed at no cost. Thirty to ninety days is a normal ask.

If you have not written the scope document yet, that is the real gap, and it is worth closing before the contract rather than after. Our guide to writing a brief for an app developer is the version of that document I would want as the buyer.

Four: change control that has a price on it

Every project changes. A contract that pretends otherwise is either naive or a trap, because the unwritten default is that every change becomes a negotiation you conduct from a weak position while the work is already half built.

Ask for three things. A written process for how a change is proposed, estimated, and approved. A rate that applies to changes, agreed now rather than quoted later. And ideally a small contingency built into the schedule, so that minor adjustments do not each trigger a paperwork cycle. The point is not to prevent changes. It is to make them boring.

Five: payments tied to milestones, not to the calendar

Paying monthly regardless of progress transfers all the risk to you. Paying on delivery of nothing until the very end transfers it all to the agency, which is why nobody sensible offers it and why you should be suspicious of anyone who does.

The workable middle is a schedule tied to milestones with named deliverables, with a meaningful final payment held until acceptance. That final tranche is your only real leverage during handover, so do not let it shrink to a rounding error. And be wary of a heavy deposit with no deliverable attached to it, which is a common feature of arrangements that end badly.

Six: the exit clause you hope never to use

Read the termination section as though the relationship has already broken down, because that is the only situation in which it will be read at all.

The questions to answer before signing: can either side terminate for convenience, and with how much notice. What do you receive on termination, and does that explicitly include the current source code, the designs, the credentials, and the documentation. Is there a termination fee, and is it proportionate. And is there a handover obligation with a stated number of days of support, because code delivered with no explanation is only slightly better than no code.

I would also look at the limitation of liability, which almost always caps the agency’s exposure at the fees paid. That is normal and I would not fight it in most cases. I would simply know it is there, because it tells you the ceiling on any remedy you are ever likely to get, and it should influence how much you rely on the contract versus how much you rely on choosing well. That choice is the subject of five red flags in app developer pitches, which is really the same argument arriving earlier in the process.

Seven: the data clause, which is not optional

If the agency will handle personal data belonging to your users, and they almost always will during testing and support, UK GDPR requires a written contract between you as controller and them as processor, covering specific points about how they may use that data. The ICO sets out what those contracts must contain in its guidance on contracts and liabilities between controllers and processors.

This one is not really a negotiation, it is a requirement, and the useful signal is how the agency reacts when you raise it. An outfit that has one ready has thought about your users’ data before. An outfit that has never heard of it is telling you something about the rest of the build too, and it usually shows up again in how they handle the wider compliance work we describe in handling GDPR in a UK consumer app.

What I would do differently

For a long time I treated contracts as the boring part at the end, a formality once the interesting conversations were over. That was wrong, and not for the reason you would expect. Negotiating these clauses is the fastest way to find out how the other side thinks. You learn more about an agency in the twenty minutes they spend explaining their intellectual property clause than in an hour of case studies.

So my honest advice is to raise all seven app development contract clauses before the proposal is final, and to treat the conversation as diligence rather than as haggling. The founder I mentioned at the start asked for an assignment on payment and got it in a day, because the agency had used a template they had never really examined. Most of the time it is that, not malice. But the template does not change unless you ask.

If you would rather see a proposal that already has ownership, access, acceptance and exit written the way this piece describes, send us a project brief and you can read ours before you talk to anyone else. And if you are still comparing options, how to evaluate an app developer’s portfolio covers the step that comes just before this one.