Web Design Milestone Payments in UK Contracts

Web design projects often go wrong because the money schedule is too vague. A client expects to pay when the site is complete, while the designer has already spent weeks on discovery, wireframes, copy coordination and development. Common mistakes include asking for one final payment only, tying payments to subjective approval, and handing over files before the invoice has cleared.

Clear web design milestone payments help both sides plan cash flow, keep decisions moving and reduce the risk of a web developer payment dispute. For designers, the aim is to avoid unpaid work and scope creep. For clients, the aim is to avoid paying too much before there is usable progress.

A well-drafted website development agreement in the UK should say what triggers each payment, what happens if feedback is late, how revisions are counted, when intellectual property transfers, and when work can be paused for non-payment.

A Milestone Structure That Keeps a Website Project Moving

A good milestone schedule links payment to clear project events, not vague progress or informal promises. The contract should make it obvious when an invoice can be issued and what the client receives at that stage.

For a typical SME website project, milestones often follow the natural order of work: deposit, strategy or discovery, design concepts, development build, testing, launch and post-launch support. The right structure depends on the size of the project, the amount of custom coding, whether content is included, and whether the client must provide brand assets or approvals.

For example, a five-page brochure website might have three payments: 40% deposit, 40% on approval of the homepage design, and 20% before launch. A more complex eCommerce build might use five or six milestones because product data, payment integrations, user testing and launch support each create different delivery risks.

Many payment problems come from confusing a project phase with a payment trigger. A phase describes work being done. A payment trigger describes the precise event that makes the invoice payable. A useful trigger might be delivery of the first design concept for client review, client approval of the staging website, or completion of the agreed pre-launch checklist.

A practical overview for web design contract payment terms could include:

• Deposit: payable when the contract is signed, before the designer allocates time or starts work.
• Discovery milestone: payable after the initial briefing session, sitemap, technical specification, statement of work or content plan is delivered.
• Design milestone: payable when agreed design concepts or page templates are presented for approval.
• Development milestone: payable when the agreed pages or functions are built on a staging environment.
• Testing milestone: payable when the site is ready for client testing, subject to agreed snagging items.
• Launch or handover milestone: payable before the site is pushed live, credentials are transferred, or final files are released.
• Support or maintenance: payable monthly, annually or as a separate block of hours after launch.

The deposit deserves particular attention. It is not just a gesture of commitment. It can cover onboarding, initial planning, reserved studio time, software setup and early work that may not be reusable if the client walks away. The contract should say whether the deposit is non-refundable, partly refundable, or credited against the total project fee.

If the client is a consumer rather than a business, consumer protection rules may affect how cancellation and prepayments are handled, including requirements under the Consumer Rights Act 2015 and consumer cancellation regulations for certain distance contracts. Most website projects for startups and SMEs are business-to-business, but a designer who sells to sole traders or individuals should be careful about how the contract describes the customer and the service.

The number of milestones should match the risk. Too many small invoices can create admin friction and arguments over minor stages. Too few milestones can leave the designer funding the project for weeks or months. A balanced payment schedule gives the client confidence that progress is being made while making sure the designer is not carrying all the credit risk.

Drafting Each Milestone Payment Clause Clearly

A milestone payment clause should say the trigger, amount, due date, evidence of completion and consequences of non-payment. If any of those points are missing, the parties may have different views about whether the invoice is valid.

Clear drafting is especially useful where the project involves creative work. A client may feel a design is not finished because they do not like the colour palette. A designer may feel the milestone is complete because the agreed concept files have been delivered. The clause should reduce that gap by describing the deliverable objectively.

A simple milestone clause might say that the client must pay 30% of the project fee when the designer delivers two homepage design concepts in PDF or prototype format for review. Another milestone might say that 25% is due when the agreed website pages have been built on the staging site and are available for client testing.

For each milestone, consider including:

• The milestone name: for example, discovery, design approval, development build, pre-launch testing or final handover.
• The deliverable: what the designer must provide, such as wireframes, design mock-ups, templates, coded pages, plug-in configuration, testing notes or launch files.
• The amount payable: a percentage of the total fee or a fixed sum excluding or including VAT, as relevant.
• The invoicing point: whether the invoice is issued on delivery, approval, deemed approval, or a listed completion event.
• The payment period: for example, payable within a set number of days from the invoice date.
• Dependencies: what the client must provide before the designer can complete that stage, such as content, images, product data or access credentials.
• What is excluded: services that are not covered by that milestone, such as copywriting, custom illustration, SEO campaigns, paid advertising setup or third-party licence fees.

Payment terms should also deal with VAT and expenses. If the designer is VAT registered, the contract and invoices should state VAT treatment clearly. If the designer purchases stock images, fonts, hosting, plug-ins or third-party tools, the contract should say whether those costs are included, passed through at cost, marked up, or paid directly by the client.

Late payment wording can also help. Business-to-business contracts in the UK may be affected by the Late Payment of Commercial Debts (Interest) Act 1998, which can allow interest and compensation for qualifying late commercial payments. Many businesses still include their own late payment provisions in their standard terms and conditions so the client understands the practical consequences without needing to search for the statutory position.

Be careful with wording such as payment due on completion. Completion of what? The whole project, the design stage, the development stage or the designer's tasks before client content is supplied? Better wording says exactly what has to happen and whether client approval is required.

A clause should also avoid making payment entirely dependent on the client's subjective satisfaction. A phrase such as payment is due once the client is happy can create an open-ended obligation. A more workable standard is that the milestone is complete when the deliverable materially matches the specification, subject to the included rounds of revisions and the agreed acceptance process.

Where the client is a limited company, the contract should name the correct contracting entity rather than only a trading name. Designers can check company names and registered details through Companies House records. This does not replace due diligence, but it can reduce confusion about who is legally responsible for payment.

Approvals, Delays and Revisions

Approval mechanics should stop a project from being held hostage by silence, indecision or endless tweaks. The contract should set a fair review period and explain what happens if the client does not respond.

Client delay is one of the biggest causes of stalled website projects. A designer may be ready to move from design into build, but the client has not approved the homepage. The client may be waiting on internal sign-off, a new logo, product descriptions or feedback from a business partner. Without a delay clause, the designer can be left with unpaid time blocked out in the schedule.

A strong website project contract in the UK should describe the approval process for each key milestone. It might say that the client has a set number of business days to approve, reject with reasons, or request included revisions. If the client does not respond within that period, the deliverable may be treated as approved for invoicing and scheduling purposes.

Deemed approval clauses can be very useful, but they should be drafted carefully. They should not let a designer ignore genuine defects. Instead, they usually say that if the client fails to provide clear written feedback within the review period, the milestone is deemed accepted and the project moves to the next stage. If the client later requests changes, those changes may be treated as additional work.

Revision wording is just as important. Many web design disputes begin with different expectations about how many rounds of changes are included. A client may assume unlimited tweaks are part of the fixed price. A designer may have priced only one or two rounds.

Good revision terms usually cover:

• Number of rounds: for example, two rounds of reasonable revisions to the selected homepage concept.
• Scope of revisions: changes to layout, colours, copy placement or images within the approved brief, not a completely new direction.
• Feedback format: consolidated written feedback from one nominated contact, rather than conflicting comments from several stakeholders.
• Timing: feedback must be given within the agreed review period to avoid pushing out the delivery timeline.
• Extra work rates: hourly or fixed fees for additional revisions, new pages, extra templates or changes after approval.

Scope creep often hides inside revision requests. A request to change a button colour may be minor. A request to add a booking system, create a membership area or rewrite all product descriptions is new work. The contract should allow the designer to issue a variation quote or change order before starting that extra work.

For clients, the practical benefit is budget control. A clear variation process means the client can decide whether a requested feature is worth the extra cost before the designer spends time on it. For designers, it creates a written record that the new work is outside the original fee.

Delays should also be linked to the project schedule. If the client misses an approval deadline or fails to provide content, the designer should not be held to the original launch date. The contract can say that delivery dates will be extended to reflect client delays and any additional time needed to reschedule resources.

A common founder moment is the launch deadline tied to a funding round, product release or marketing campaign. If that date matters, both sides should identify the client inputs needed early. Copy, imagery, policies, product information, payment gateway details and domain access often take longer than expected.

Where a website collects personal data, privacy compliance may also become a project dependency. A client may need a privacy notice, cookie wording, consent settings or data processing arrangements. UK GDPR and the Data Protection Act 2018 can be relevant if the site processes personal data, uses analytics, captures enquiries or runs user accounts. The designer's role in privacy work should be clearly stated so it does not become an assumed extra.

Handover, IP and Suspension for Non-Payment

Final payment should usually be due before launch, file release, credential transfer or full intellectual property assignment. Otherwise, the designer may lose leverage at the moment the client receives the most valuable part of the project.

Handover is more than pressing the launch button. It can involve transferring source files, admin access, hosting control, domain records, code repositories, theme files, brand assets, CMS training notes and third-party account details. The contract should say exactly what is handed over, when it is handed over, and what is only provided after cleared payment.

Intellectual property is often misunderstood in web design projects. In the UK, copyright is governed by the Copyright, Designs and Patents Act 1988. As a starting point, the person or business that creates original design, code, copy or graphics may own copyright, unless there is an employment relationship or a written assignment that changes ownership. Paying an invoice does not automatically transfer all copyright in every asset.

A web design contract, or customer contract for the wider project, should say whether the client receives an assignment of IP, a licence to use the website, or a combination. Many designers assign the final approved website materials after full payment, while retaining ownership of pre-existing tools, reusable code, templates, know-how and rejected concepts. That approach can be commercially sensible, but it needs to be written down.

For clients, IP wording should give enough rights to operate, maintain and develop the website. A client who plans to hire another developer later will want access and rights broad enough to update the site. For designers, IP wording should protect reusable methods and prevent the client from using unpaid or rejected concepts.

Third-party materials require separate treatment. Stock photos, fonts, plug-ins, themes, APIs and software platforms are often governed by their own licence terms. A designer cannot assign ownership of materials they do not own. The contract should explain whether the client is responsible for complying with third-party licences and ongoing subscription costs.

Suspension rights are another key protection against non-payment. A fair suspension clause gives the designer the right to pause work if an invoice is overdue, after giving written notice. It should also explain what happens to deadlines, booked work and restart costs.

A practical suspension clause may cover:

• Notice: the designer will notify the client that payment is overdue before suspending work.
• Pause rights: the designer may stop work, withhold handover materials or delay launch until overdue amounts are paid.
• Timeline changes: project dates move out to reflect the suspension and the designer's next available schedule.
• Restart fees: the client may need to pay reasonable costs if the project has to be re-onboarded after a long pause.
• Service limits: any hosting, maintenance or support included in the project may be paused if the relevant fees are unpaid.

The clause, including any limitation of liability wording, should be proportionate. A designer should avoid taking steps that could create unnecessary damage to the client's live business, especially if the dispute is about a small part of a larger invoice. For example, it may be more appropriate to withhold new development work or final handover rather than disrupt an existing live site without warning.

Clients should also protect themselves against overpayment risk. If a designer asks for most of the fee upfront, the client can ask for a more balanced milestone schedule, evidence of previous work, a clear specification and a handover plan. A staged payment model works best when each side gives something of value at each stage.

Termination wording should connect to milestones too. If either party ends the project early, the contract should say what happens to work already completed, unpaid invoices, deposits, work in progress and licences. For example, the client may need to pay for completed milestones and approved extra work, while the designer may need to deliver paid-for materials that have been completed.

Many web developer payment disputes can be avoided with a simple paper trail. Approvals, revision requests, variation quotes and late payment notices should be in writing. A phone call can be useful for keeping the relationship friendly, but the decision should be confirmed by email or through the project management tool named in the contract.

FAQs

Should A Web Designer Ask For A Deposit?

Yes, in most commercial projects a deposit is sensible because the designer commits time, starts planning and may incur setup costs before visible work is delivered. The contract should state whether the deposit is refundable, non-refundable or credited against the total fee.

Can A Milestone Be Payable Before The Client Approves The Work?

Yes, if the contract says payment is triggered by delivery of a specified item rather than approval. Many contracts use a mixed approach, with some invoices due on delivery and others due on approval or deemed approval after a review period.

What Happens If The Client Does Not Provide Content On Time?

The contract should allow the timeline to move, the milestone to be invoiced if the designer has completed their dependent tasks, or the project to be paused until content is supplied. The best option depends on whether the missing content blocks the whole stage or only part of it.

Can A Designer Refuse To Launch A Website Until Paid?

Often, yes, if the contract makes final payment a condition of launch or handover. The clause should be clear, proportionate and linked to overdue amounts, with notice before suspension where appropriate.

Who Owns The Website After The Final Payment?

Ownership depends on the IP clause. The client may receive an assignment of the final approved materials, a licence to use them, or rights limited by third-party licences and the designer's pre-existing tools.

Key Takeaways

• Web design milestone payments should be tied to clear deliverables, such as design concepts, staging builds, testing readiness and final handover.
• A milestone payment clause should identify the trigger, amount, due date, review process, dependencies and consequences of non-payment.
• Approval and deemed approval wording can prevent projects from stalling when feedback is late or unclear.
• Revision limits and variation processes help separate included tweaks from new work, which reduces scope creep.
• Final payment, IP transfer, launch and handover should be coordinated so neither side gives away too much too early.
• Suspension and termination clauses should be practical, proportionate and supported by written notices and records.

If you need help structuring your web design agreement, milestone payment clauses, revision terms, IP handover wording or suspension process, Sprintlaw's legal team can help you get the contract in shape. Contact us on 08081347754 or team@sprintlaw.co.uk for a free, no-obligations chat.