Why This Matters More Than It Seems
Almost every serious dispute between a business and a web studio traces to one of four things: what was in scope, who owns the output, what happens when things change, and what you receive if it ends. All four are contract questions, and all four are cheap to settle before work begins and expensive to argue afterwards.
What follows is written from the client side, though a good studio will happily agree to most of it — clarity protects both parties, and the studios that resist these terms are usually the ones you most need them with.
1. Intellectual Property and Ownership
The clause to read first. In many jurisdictions, copyright in commissioned creative work stays with the creator unless assigned in writing. Paying for it is not the same as owning it.
What to look for
- Explicit assignment of copyright and IP in the final deliverables to you, effective on final payment
- Coverage of everything — code, design files, custom illustration, custom photography, custom fonts where licensing permits
- Clarity on third-party components — themes, plugins, stock imagery, licensed fonts remain under their own licences, and the contract should list what those are and who pays for them ongoing
- Retained rights for the studio's own reusable frameworks and tooling, which is entirely reasonable, provided your site does not stop working without them
- Portfolio rights for the studio to show the work, which is normal — negotiate timing if you need a confidential period
What to refuse
- A licence to use the website rather than ownership of it
- IP that transfers only if you continue a maintenance retainer
- Silence on the subject, which defaults against you
- Proprietary frameworks that only that studio can maintain, without a stated exit path
The practical consequences of getting this wrong are set out in our guide to website, domain and hosting ownership.
2. Scope of Work
Scope disputes are rarely bad faith. They are two parties who read the same sentence differently.
Specify
- Number of unique page templates, not pages — and what a template means
- Whether design covers mobile, tablet and desktop, and which states (empty, error, loading, logged-in)
- Who supplies copy, and what happens if it is late
- Who supplies imagery, and whether stock licensing is included
- Every integration, named individually
- Browser and device support, as an explicit list
- Accessibility standard being worked to, if any
- Performance targets, as numbers
- Training and documentation at handover
- An explicit out of scope section — the most useful paragraph in most contracts
3. Changes and Revisions
Change is normal. Undefined change is what causes trouble.
- Revision rounds included per phase, with a definition of what a round is
- The hourly or day rate for work beyond the included rounds, stated in the contract rather than quoted later
- A written change-request process: request, estimate, approval, then work
- What happens to the timeline when scope is added, so that changes have a visible schedule cost as well as a financial one
- How phase sign-off works, and what reopening a signed-off phase costs
Watch for "unlimited revisions". It is priced on the assumption you will not use it, and it removes any definition of when a phase is finished, which harms both sides.
4. Payment Terms
| Structure | Assessment |
|---|---|
| 30 to 50 percent deposit, milestones, 20 to 25 percent on handover | Standard and healthy |
| Monthly instalments across the project | Fine, if tied to delivered milestones |
| 100 percent up front | Refuse, other than for very small fixed pieces of work |
| Final payment due at launch, not at handover | Change it — handover is what you need leverage over |
| Ongoing fee required to keep the site running | Only acceptable as a genuine, cancellable service |
Also confirm: currency and who bears exchange or transfer fees on cross-border work, what late payment triggers, and whether the deposit is refundable if the studio cannot start.
5. Handover: The Clause Everyone Forgets
Define handover as a deliverable with a list, not as an event.
- Repository access, or a full code archive, transferred to your account
- Editable design source files
- Administrative access to every system, with your own credentials
- Domain registered in your name, in your registrar account
- Hosting in your account, or transferable on request
- Analytics and search console owned by you
- Documentation covering how to edit, deploy and maintain
- A list of every third-party service, its cost, and its renewal date
Set these up in your name at the start of the project rather than transferring them at the end. Transfers get forgotten; day-one ownership does not need transferring.
6. Termination and Exit
Nobody enjoys negotiating this and everybody who has needed it wishes they had.
- Notice period for either party
- Payment for work completed to the termination date, and how that is calculated
- What you receive on exit — ideally everything completed and paid for, in usable form
- Whether IP assigns for the portion paid, which it should
- Kill fee, if any, and its size
- A transition obligation — reasonable cooperation with an incoming team, and at what rate
7. The Rest, Briefly
- Confidentiality, mutual, particularly if the team touches customer data
- Data protection — a data processing agreement where UK or EU personal data is involved
- Warranty period — 30 to 90 days of bug fixes after launch at no charge, with a clear line between a defect and a new request
- Liability cap, commonly the project fee, which is normal
- Governing law and dispute mechanism, which matters most on cross-border engagements
- Client obligations, stated explicitly — a fair contract binds both parties to timelines
Red Flags in the Document Itself
- No written contract at all, only an emailed quote
- No IP clause, or one that is deliberately ambiguous
- Deliverables described in adjectives rather than nouns
- Domain or hosting to be registered in the studio's name
- No termination provision
- Automatic renewal of a retainer with a long notice period
- Anything requiring an ongoing payment to retain access to your own site
- Resistance to being asked about any of the above
That last one is the most reliable signal in the list. A studio that takes these questions as reasonable is telling you how the project will be run. A studio that treats them as distrust is telling you the same thing.
Before You Sign
- Read the whole document, including the appendices where scope usually hides
- Confirm the IP clause assigns ownership to you on final payment
- Confirm the deliverables list is specific enough to be checked off
- Confirm the final payment is tied to handover
- Confirm you own the domain, hosting and analytics accounts from day one
- Confirm exit terms exist
- Ask about anything unclear in writing, and keep the reply
- For engagements above a meaningful threshold for your business, have a solicitor read it
Kalex Studio contracts assign ownership on final payment, list deliverables specifically, and hand over every account and source file at the end as a matter of standard practice. If you would like a second read of a contract you have been sent, we are happy to point out what we would push back on. This article is general guidance rather than legal advice — take advice from a qualified professional in your jurisdiction for anything consequential.