The twelve questions a contract should answer
| Clause | The question it should answer |
|---|---|
| Scope | What exactly is being built, and what is out of scope? |
| Deliverables and acceptance | How do we both agree something is finished? |
| Milestones and payment | What do I pay, when, and for what working result? |
| Changes | How is a new request priced and approved before work starts? |
| Ownership of code and IP | When does ownership move to my company, and for which countries? |
| Accounts and access | Whose name are the repository, hosting and store accounts in? |
| Confidentiality | Does it cover the agency's staff and any subcontractors? |
| Data protection | Which privacy laws apply, and how is personal data handled? |
| Warranty | For how long are bugs fixed for free, and what counts as a bug? |
| Support after launch | What's covered after the warranty, and how is it paid for? |
| Ending the project | If either side stops, what do I receive and how fast? |
| Disputes | Which country's law applies, and how are disagreements resolved? |
The clauses buyers most often get wrong
Scope without exclusions
A feature list isn't enough. The contract, or the scope document it refers to, should also list what's not included. Most disputes start with something each side assumed the other had agreed to."Done" left undefined
Acceptance criteria turn "is it finished?" into a checklist. They should say what you'll test, where, and how long you have to review before a milestone counts as accepted.Ownership without accounts
An IP clause matters, but so do the accounts the product runs on. Our guide to who owns the code when you outsource explains why payment alone doesn't make you the owner, and which accounts must be in your name.No exit plan
Nobody plans to stop halfway, which is exactly why it should be written down. You should keep everything delivered and paid for, with access and a handover, whatever the reason for stopping.Support assumed, not agreed
A warranty covers defects in what was delivered, for a fixed period. Ongoing updates, monitoring and new features are maintenance, usually agreed separately. What a maintenance plan should cover explains the difference.Working across countries
If you and your developer are in different countries, three points need extra care: which country's law governs the contract, how disputes are resolved without travelling to court abroad, and which data protection rules apply to your users. Agree these up front rather than after a problem.Signs a contract is too thin
- It refers to "the project" without attaching a written scope
- Payments are tied to dates, not to working software
- Ownership isn't mentioned, or moves only when the whole project is paid off
- There's no clause on ending the project early
- Changes are "billed as required" with no approval step
- Confidentiality covers the company but not the people doing the work
How we handle contracts
Nothing starts on a handshake. We sign an NDA first if you want one, send a written scope after the scoping call, and only start once the agreement is signed. You can read how that works on our contracts and NDA page. We share our standard agreement after scoping, and we're happy to review yours instead.FAQ
Do I need a lawyer to review a software development contract?
It's worth it for anything beyond a small job, especially across countries. A lawyer can check ownership, liability and dispute terms against your local law.Should the scope be in the contract or a separate document?
Either works, as long as the contract refers to a specific, dated scope document and says how changes to it are agreed.Can I use my own contract with an agency?
Usually, yes. Many agencies will review yours. Make sure it still covers acceptance, changes and handover, which generic templates often miss.Getting ready to sign with a development partner? Book a free scoping call and get a written scope to put in front of your lawyer.
