Quick answer
Before signing a software development contract, check five things: you own the code and get a full copy, scope and price are written down, payments follow delivered milestones, changes are priced before work starts, and you can leave with your data and a proper handover. If any of these is vague or missing, ask for it in writing.
A contract for custom software, a web app or a booking system is easy to skim and expensive to get wrong. Most disputes between small businesses and developers come from what the contract did not say rather than what it did. This guide lists the red flags to look for, what good wording covers instead, and a checklist you can work through before you sign. It is practical guidance, not legal advice: for a large or unusual project, have a solicitor read the final draft.
Why the contract matters more for software
A logo or a printed leaflet is finished when it is delivered. Software keeps living: it needs hosting, updates, fixes and new features, and it holds your business data. That means the contract has to answer questions that other design work never raises. Who owns the code? Where does it run? What happens if the developer stops trading? Who fixes a bug found six months after launch?
If the answers are not written down, the default position can surprise you. GOV.UK’s guidance on ownership of copyright works explains that someone working under a contract for services, such as a freelancer or agency, will usually keep the copyright in what they produce unless the contract says otherwise. Paying for software does not automatically mean you own it.
The 12 red flags at a glance
| Red flag | Why it matters | Ask for instead |
|---|---|---|
| No mention of who owns the code | The developer may keep copyright by default | Ownership, or an assignment of rights, on full payment |
| Code hosted only in the developer’s accounts | You cannot move without their help | Code in a repository and hosting account in your name |
| “Scope to be agreed” or a one-line description | Every extra becomes a dispute | A written list of features and what is out of scope |
| Most of the price paid upfront | You lose leverage if delivery slips | Payments tied to delivered, tested milestones |
| No change request process | Costs creep without warning | Changes quoted in writing before work starts |
| Open-ended hourly billing with no cap | No ceiling on the final bill | A fixed price, or an estimate with a cap |
| No acceptance testing period | “Delivered” means whatever they say it means | A set number of days to test and report faults |
| No bug-fix period after launch | Early faults are billed as new work | A stated period for fixing defects at no charge |
| Licence fees for the developer’s own framework | A hidden yearly cost that never ends | A list of every licence and who pays for it |
| Long minimum support term you cannot exit | You pay for support you do not need | Support as a separate, cancellable agreement |
| Nothing on data protection | Your customers’ data has no written safeguards | Data processing terms and security basics |
| No exit or handover clause | Leaving becomes slow and costly | Code, data, documentation and credentials on exit |
Ownership and access
This is the clause to read first. Look for wording that says the intellectual property in the bespoke code passes to you, usually once you have paid in full. Developers often reuse their own libraries across projects, which is normal; the contract should then give you a permanent licence to use those parts, so your software keeps working whatever happens to the developer.
Access is the practical side of ownership. Ask for the code to live in a repository you own, for the hosting and domain to be in your name, and for admin logins to be handed over at launch. Our guide to client portals for small businesses covers the same point for customer-facing systems.
Scope, price and change requests
A good contract attaches a scope document: the screens, features, user roles and integrations included, and a short list of what is not. Vague scope is the most common cause of a final bill far above the quote. If the developer resists writing it down, that tells you something.
Changes are normal. You will think of things once you see the first version. The contract should say how a change is requested, that it will be priced and timed in writing, and that nothing is billed until you approve it. Our guide to web app development costs explains what drives the price of each feature, which helps you judge whether a change quote is fair.
Payment terms that protect both sides
A deposit is reasonable: the developer is reserving time for you. After that, payments should follow delivered work you can see and test, not dates on a calendar. A typical structure is a deposit, one or two milestone payments, and a final payment on acceptance.
Check the payment period too. GOV.UK’s guidance on late commercial payments says an agreed payment date between businesses must usually be within 60 days, and that a longer period must be fair to both sides. Agree terms you can actually meet, because late payment can give the supplier the right to charge interest.
Testing, acceptance and warranty
“Delivered” and “finished” are not the same. Look for an acceptance period, often a couple of weeks, when you test the software against the agreed scope and report faults. Once accepted, a warranty or bug-fix period should cover defects in the agreed features. Without one, every fault after launch can be billed as new work.
Be fair in return: a warranty covers things that do not work as agreed, not new ideas or changes caused by someone else editing the code.
Security and data protection
If the software stores customer details, bookings or payments, the contract needs data protection terms. Under UK GDPR, a developer or host that handles personal data on your behalf usually acts as a processor, and a written contract with set terms is required between you. Ask where data is stored, who can access it, how backups work and what happens to the data when the contract ends.
The government’s Software Security Code of Practice sets out what good software suppliers should do on security. You do not need to read it all, but asking a developer whether they follow it is a quick way to see how seriously they take the subject.
Support, hosting and the exit clause
Support is often where long-term costs hide. Keep it as a separate agreement with a clear monthly price, response times and the right to cancel. A clause that ties support to ownership, so you lose the code if you stop paying for support, is a serious red flag.
The exit clause should list what you get if the relationship ends: the full source code, a database export, documentation, every password and API key, and a reasonable period of help to move. Our list of signs a web designer is overcharging covers the hosting and renewal markups that often sit alongside weak exit terms.
A pre-signing checklist
| Check | Where to look | Done? |
|---|---|---|
| Bespoke code ownership passes to you on payment | Intellectual property clause | ☐ |
| Licence to reused components is permanent | Intellectual property clause | ☐ |
| Repository, hosting and domain in your name | Delivery or handover section | ☐ |
| Scope document attached, with exclusions | Schedule or appendix | ☐ |
| Payments tied to milestones you can test | Fees and payment | ☐ |
| Changes priced in writing before work | Change control | ☐ |
| Acceptance period and bug-fix period stated | Acceptance and warranty | ☐ |
| Data protection terms included | Data or confidentiality clause | ☐ |
| Support separate and cancellable | Support schedule | ☐ |
| Exit: code, data, documentation, credentials | Termination clause | ☐ |
Questions to ask before you sign
- When does ownership of the code pass to us, and is that in the contract?
- Which parts are your own reusable components, and what licence do we get to them?
- Whose name will the hosting, domain and code repository be in?
- How do you price a change, and how quickly do we get the quote?
- What happens if you are unavailable for a month, or stop trading?
- What exactly do we receive if we move to another developer?
A good developer will answer these without hesitation, because they protect the developer too: clear scope and clear payment terms prevent the arguments nobody wants.
How we handle it
Our Custom Business Software starts from £1,499, with a fixed quote and a fixed timeline agreed before work starts, and you own 100% of the source code. For customer-facing portals and booking systems, our Web Applications start from £1,999. You can see every fixed price on our pricing page, and our booking system cost guide compares off-the-shelf and custom routes if you are still deciding what to build.
Get the UK Website Project Brief Template (free)
A two-page template for briefing any UK web designer: sitemap, integrations, audience and deliverables. Cuts revision rounds in half.
No spam. UK GDPR compliant. We only use your email to send this resource, unless you tick the box to hear from us.
Frequently asked questions
Who owns the code in a software development contract? +
It depends on the contract. GOV.UK guidance says someone working under a contract for services, such as a freelancer or agency, usually keeps the copyright in what they produce unless agreed otherwise. Make sure the contract says ownership of the bespoke code passes to you, usually on full payment, with a permanent licence to any reused components.
How much deposit should a software developer ask for? +
There is no fixed rule, but a deposit to reserve the developer's time is normal. After that, payments should follow milestones you can see and test, with a final payment on acceptance. Be wary of contracts that ask for most of the price before any working software has been delivered, because you lose leverage if delivery slips.
What should happen if I want to change the scope? +
The contract should set out a change process: you request the change, the developer quotes the cost and time in writing, and nothing is built or billed until you approve it. Without this, small extras add up quietly and the final bill can land far above the original quote, with no paper trail to check it against.
Do I need a solicitor to review a software contract? +
For a small, fixed-price project with clear terms, many businesses review it themselves using a checklist like the one in this guide. For a large project, anything handling sensitive data, or a contract with unusual liability or licence terms, it is worth paying a solicitor to read the final draft before you sign it.
Will I own the source code if you build my software? +
Yes. Our Custom Business Software starts from £1,499 with a fixed quote and a fixed timeline agreed before work starts, and you own 100% of the source code. Customer-facing portals and booking systems sit under our Web Applications, which start from £1,999. Every fixed price is listed on our pricing page.
