Once you have chosen a website redesign proposal, check that the agreement describes the website you expect to receive and what happens when the project ends. A clear proposal can still leave open questions about content ownership, changes to scope, access to accounts and ongoing fees. Resolve those before work begins.
This is a commercial discussion guide for UK SMEs, not legal advice or a contract template. If the terms carry material risk for your business, have a qualified adviser review the agreement. To compare offers before choosing a supplier, start with our proposal comparison guide.
Can both sides identify the finished deliverables?
The agreement should connect the fee to a scope that can be recognised at handover: page types, approximate content volume, design work, development, forms, integrations, migration and training where relevant. It should say what the business provides, such as approved copy, photographs, product data or access to an existing platform.
Ask how a change to that scope is requested, assessed and approved. If a new service section is added midway through design, is that a revision within scope or a new piece of work? A sensible change process protects both the client and the supplier from relying on an informal conversation neither remembers in the same way.
Who decides when a stage is complete?
Make review points visible. A page structure may need approval before copy and design can settle. A working site needs testing before it can be accepted for launch. Ask how many rounds of changes are included, what feedback must be consolidated and how defects found during testing are handled.
“Approved” should mean something specific. Approving a design direction is different from confirming that every link, form and redirect works. For a redesign, the agreement should also identify who has authority to approve the old-to-new page mapping. The project responsibility guide helps assign these decisions inside the business.
What will the business own or be licensed to use?
Ask about the website code, design files, copy, photographs, fonts, plugins and any third-party components. Different materials may have different rights and licence terms. Do not assume that paying for a project automatically transfers every right in every asset. The UK Intellectual Property Office's guidance on commissioned copyright work explains why ownership should be agreed in writing.
A practical question is whether the business will be able to use, maintain and move the finished site as expected, including if it later changes supplier. Ask which source files and credentials will be supplied, which assets rely on continuing licences and whether any reusable supplier tools remain under the supplier's ownership. Get the answer in the agreement, rather than relying on a phrase such as “full ownership” without detail.
Which accounts and recurring costs sit with whom?
List the domain, hosting, content management system, analytics, Search Console, email-related services, form handling and any paid integrations the site uses. Confirm who opens each account, who pays the provider, who holds administrative access and what happens if the working relationship ends. This matters particularly when an existing account is already part of the business's operations.
Separate the one-off redesign fee from hosting, licences, updates and support. State whether ongoing services are optional, what they cover and how they can be changed or cancelled under the proposed terms. The wider redesign cost guide covers these budget categories; the agreement should make the actual commitments unambiguous.
What does handover include?
Handover is more than switching the site live. Ask for a list of account access, basic editing guidance, any agreed technical documentation, the location of assets and the support route for a launch issue. Confirm whether the supplier will check forms, redirects and key pages after publication, and when responsibility for routine updates passes to the business.
If the project has an important date, look at the assumptions behind it: content delivery, approvals, third-party access and testing time. A clear agreement should explain what happens when one of those dependencies moves, without pretending that all delay is in one party's control.
Leave the meeting with written answers
You do not need an agreement that predicts every possible change. You need one that states the intended result, the boundaries of the work, how changes are decided and how the business continues to operate the site afterwards. If an important answer is only in an email or a sales conversation, ask for the proposal or agreement to reflect it before signing.
For an existing website, those details should be discussed alongside the pages and processes already in use. The agreement is more useful when it describes the work required to move from that starting point to the intended result.