The web developer's guide to contracts and invoicing (UK)

The biggest risk on a freelance development project usually isn't the day rate — it's the scope. A price gets agreed against a rough idea, then the work quietly grows: an extra page here, a "quick" integration there, a redesign of the thing you'd already built. None of it feels like much on its own, and all of it lands on you. A good agreement's real job is to turn "can you just also…" into a priced change rather than free work.

This guide covers the terms that matter for development work specifically — scope and change requests, who owns the code, how delivery and revisions are handled, and what happens after launch — then how to price and invoice so you're paid on time.

A quick note first: TrustSolo isn't a law firm or an accountancy, and nothing here is legal advice. Its contract templates are customisable starting points, not solicitor-reviewed documents — for a high-value or unusual engagement, a professional opinion is worth the money.

Why a written agreement matters for developers

Development has a particular way of going wrong, and it's rarely the code. It's that software is almost infinitely adjustable, so the line between "finishing the agreed work" and "building something bigger" is blurry unless someone draws it. A client isn't usually being difficult when they ask for more — they often don't realise a request is out of scope, because to them it's all just "the website". The written agreement is what makes that boundary visible to both of you, calmly and in advance.

It also settles a question that's easy to leave unspoken until it's awkward: who ends up owning the code, and whether the client gets the source. Neither of you wants to be having that conversation after launch. Agreeing it up front costs a sentence; leaving it costs a good working relationship.

A clear agreement, sent before the work starts, handles both quietly — and makes you look like the professional you are.

Scope, exclusions and change requests

This is where development projects are won or lost financially, so it's worth doing properly. Three things belong in the agreement:

• What you're building. As specific as you can manage — the pages or features, roughly what each does, and the deliverables. Vague scope against a fixed price is the quickest way to lose money in this trade.
• What you're not building. The exclusions do as much work as the scope itself. Content, copywriting, hosting, SEO, ongoing maintenance, third-party licences, browser or device support beyond an agreed list — spelling out what's excluded is what stops each of them being quietly assumed in.
• How changes are handled. A single line that work beyond the agreed scope is quoted and agreed in writing before it's done. This isn't being awkward; it's the one mechanic that keeps a fixed-price project profitable. It also protects the client, who gets to decide whether a change is worth the cost rather than finding it on the final invoice.

One more clause earns its place: where delivery depends on the client — content, approvals, access, assets — a delay on their side reasonably extends your timeline. It's fair, and it stops someone else's hold-up becoming your missed deadline.

TrustSolo's web-development contract template is built around exactly this — a defined scope with an exclusions list, a written-variation process for extra work, and a client-dependency clause — as a customisable starting point you adjust per project. You can see how it works under contracts.

Who owns the code — IP and source files

Here's the part many developers get backwards. Under UK copyright law (section 11 of the Copyright, Designs and Patents Act 1988), the person who creates a work is usually its first owner. As gov.uk puts it, for commissioned work "the first legal owner of copyright is the person or organisation that created the work and not you the commissioner, unless you otherwise agree it in writing." In plain terms: unless your contract says otherwise, you keep the copyright in the code you write — even though the client commissioned and paid for it.

That isn't the same as the client having no right to use what they paid for. The same guidance notes that where copyright isn't dealt with in the contract, courts "may be willing to find that there is an implied licence allowing the commissioner to use the work for the purpose for which it was commissioned" — which "does not necessarily result in a transfer of ownership. Instead, the commissioner of the work may only get a limited non-exclusive licence." So silence doesn't hand you leverage; it hands both of you an argument, to be settled later by someone else.

That's precisely why the IP clause matters, and why it's a genuine commercial choice rather than a formality:

• Transfer the IP. Ownership passes to the client — commonly on full payment, which neatly means they don't own it until they've paid. When you transfer ownership, the source code goes with it: you can't own something you can't access.
• Retain the IP and licence it. You keep the copyright and grant the client the right to use the work. This fits a hosted product, a proprietary platform, or anything you intend to reuse — and it lets you withhold the source in a licence-only arrangement, if that's the deal.

Either is fine; what isn't fine is leaving it unsaid. Decide it, write it down, and make sure the source-code and file position matches the ownership you've agreed.

Delivery, revisions and life after launch

Delivery. Bigger builds are usually delivered in milestones — reviewed in stages, so problems surface early and payments can track progress. Smaller pieces work as a single delivery reviewed on completion. Either way, say which in the agreement, and document the stages in your scope.

Revisions. Include a defined number of revision rounds within the original brief, and a rate for anything beyond. The distinction that saves you is between a revision — a change to existing work inside the agreed scope — and a new feature or a change of direction, which is fresh scope and a separate quote. On milestone projects, the included rounds apply per milestone.

After launch. A short defect period — fixing genuine bugs free for a set time after handover — is fair and normal, and worth offering. What shouldn't be folded into the build fee is open-ended support: ongoing hosting, maintenance, updates and new features are a separate arrangement, best handled under a maintenance retainer priced on its own. Drawing that line at handover keeps you from doing months of unpaid support because "it's basically part of the project".

Pricing, deposits and getting paid

Development work is usually priced as a fixed project fee, by the day, or by the hour — and the right choice mostly comes down to how firmly the scope is nailed down. Fixed pricing rewards you for being fast and experienced, but you carry the risk if the job overruns, which is exactly why a tight scope and a change-request process matter so much. A day rate suits discovery or evolving work where the shape isn't settled — it puts the cost of changing direction with the client, where it belongs. Hourly tends to fit small, reactive jobs like bug fixes and ad-hoc support. For a sense of the going rate, see what UK web developers charge; the free rate calculator then works backwards from the income you need to a sustainable figure.

Whatever the headline model, a couple of mechanics protect a development project specifically. Take a deposit up front and, for anything sizeable, tie further payments to milestones — design signed off, build complete, launched — so you're never far out of pocket if a project stalls. And pass third-party costs (hosting, domains, paid plugins, stock assets) through to the client rather than absorbing them, ideally noting in the agreement that they're the client's responsibility.

Your invoice then follows the same rules as any freelance invoice — a unique number, your details and the client's, a clear description, the amount and a due date. Our guide to how to invoice as a freelancer covers exactly what to include. If a payment runs late and your client is a business, you have the same statutory protections as any freelancer — the right to charge interest of 8% plus the Bank of England base rate, plus a fixed recovery cost; our guide to late-paying clients walks through the whole escalation ladder. As ever, prevention beats cure: a deposit up front, staged payments, and a due date on every invoice. For the underlying terms every freelance contract should carry, the six clauses every freelance contract needs is a good companion read.

How TrustSolo helps developers

TrustSolo is built to take the admin off your desk. The web-development contract template gives you a customisable starting point covering scope and exclusions, change requests, IP transfer or licence, source-code delivery, revisions and the defect period; the invoicing handles your deposit-and-milestone billing with a payment link attached; and a running estimate of your Income Tax and Class 4 National Insurance keeps your numbers in view as you go. It's there to make the business side quiet and predictable, so your attention stays on the build — with the commercial choices left to you.

The view tailored for web developers lives at TrustSolo for web developers.

Get the agreement and the invoicing set up once and development becomes mostly what you came here to do. When you'd like the paperwork to look after itself, you can start free — no card required.