An illustrative budget model for bespoke UK websites

Use visible planning assumptions instead of one universal price

A bespoke website is not a standard object with one responsible UK price. A focused site for one offer and one conversion path is materially different from a multilingual publishing platform with hundreds of migrated URLs, account areas, CRM and commerce integrations, advanced search, complex permissions, and several internal publishing teams. The useful first answer is therefore a conditional range tied to a named release, its content, and the evidence required before launch.

For early planning, this guide models a focused bespoke commercial site as 15–35 person-days at £350–£550 per day, producing £5,250–£19,250. A content-led site with a broader design system, structured publishing, and several journeys is modelled as 40–80 person-days at £450–£700, producing £18,000–£56,000. A complex multi-system website is modelled as 80–160+ person-days at £600–£900, producing £48,000–£144,000+. One person-day means one person working for one day, not a calendar day or an entire team day. The rates are hypothetical blended assumptions chosen to expose model sensitivity, not observed supplier rates. This editorial method was reviewed on 16 August 2026.

These arithmetic bands are planning scenarios, not advertised charges, market averages, Blancc prices, quotations, guarantees, or evidence that a particular project belongs in a band. VAT is not included and should be added where applicable; an actual supplier proposal should state its VAT treatment clearly for the intended customer. The bands also exclude client staff time, copy production, photography, film, illustration, font and stock licences, hosting, domains, paid software, accessibility or security audits, translation, legal advice, data cleansing, and other third-party costs unless a proposal expressly includes them. Reproduce the displayed service-fee bands by multiplying the stated days and rate assumptions. Build a fuller project budget by then adding named external costs and a separately stated risk allowance.

• Focused scenario: 2–5 discovery days, 4–9 content and journey days, 5–14 design and build days, and 4–7 assurance and delivery days
• Content-led scenario: 5–10 discovery days, 10–20 content and information-architecture days, 18–35 design and build days, and 7–15 assurance and migration days
• Complex scenario: 10–20 discovery days, 18–35 content and design days, 35–75 engineering and integration days, and 17–30 assurance, migration, and release days
• State whether VAT, expenses, licences, hosting, client time, specialist reviews, and contingency are included
• Replace every illustrative input with a discovery-backed role plan before authorising delivery

Define the website’s job and release boundary before estimating

Begin with the audience, current problem, offer, evidence, desired action, publishing operation, and measurable purpose of the first release. The GOV.UK Service Standard is written for public services, but its principles—understand users, solve the whole problem, make the service simple and accessible, define success, choose appropriate technology, and operate reliably—provide a useful checklist for a commercial website brief. A visual redesign is not a complete scope when the real problem is unclear positioning, missing evidence, fragmented content, or an unreliable lead handoff.[1]

Describe the release in observable terms. Name the priority audiences and journeys; required content types and templates; navigation and search; forms and confirmation; CMS roles and approvals; languages and territories; analytics requirements; integrations; downloads; redirects; administration; error states; and support path. Distinguish reusable templates from individual pages. A five-page site can require substantial work when every page needs original research, complex interactions, new photography, and a CRM workflow, while a larger site can be efficient when content and components follow a coherent model.

Map decision dependencies as part of the estimate. Record who supplies source material, who can approve proposition and copy, which systems have technical owners, which claims need evidence, which legal or brand reviews apply, and how quickly feedback will be consolidated. A supplier cannot price certainty that the client has not created. When content, access, or integration decisions remain unresolved, use a discovery stage or bounded allowance instead of hiding uncertainty inside a fixed headline fee.

• Name the primary audiences, jobs, journeys, and measurable purpose
• List content types, reusable templates, interactions, systems, roles, and important exceptions
• Separate confirmed requirements from assumptions, options, and later roadmap ideas
• Assign one authorised owner for content, technology, evidence, and final approval

Price content, migration, integrations, and assurance as delivery work

Content is not the text placed into finished boxes after design. Useful website delivery can require proposition work, customer and stakeholder interviews, page planning, information architecture, copy, evidence gathering, image selection, metadata, accessibility review, and CMS entry. State whether the supplier creates, edits, structures, migrates, or merely receives final content. Also state how many content rounds, languages, documents, products, people, locations, and legacy pages the estimate assumes. A design programme can stall even when its screens are approved if nobody owns the words and proof required to publish them.

Migration is an SEO, data, and operational project rather than a launch-day upload. Google’s site-move guidance recommends inventorying old URLs, mapping each one to the most relevant new destination, using server-side permanent redirects, updating internal links and canonicals, providing a new sitemap, retaining verification, and monitoring the move. The website budget should identify who crawls the current site, preserves valuable files and metadata, maps URLs, implements and tests redirects, validates analytics and Search Console, and monitors unexpected errors. Removing or redirecting every old URL to the home page is not a responsible migration plan.[3]

Accessibility, privacy, and security also require activities and evidence. W3C publishes WCAG as a shared accessibility standard. The ICO says data protection should be integrated from design and throughout the processing lifecycle. The NCSC’s secure-development principles cover maintainable code, development environments, repositories, build pipelines, continual testing, and planning for flaws. A proposal should translate applicable requirements into design decisions, technical controls, testing, documentation, and owners; a generic claim that a site is compliant does not explain the work or replace specialist advice where it is needed.[4][5][6]

Use the website migration SEO checklist to turn the URL and launch scope into a testable cutover plan ↗

• Define who researches, writes, approves, enters, migrates, and maintains each content type
• Inventory legacy URLs, files, metadata, traffic value, redirects, and verification before launch[3]
• Run a technical spike when an integration, data source, or platform constraint could reverse the estimate
• Specify browser, device, keyboard, assistive-technology, performance, privacy, and security checks
• Treat specialist legal, accessibility, security, photography, or translation work as named external cost

Separate the build from first-year operation and ownership

Launch changes the work; it does not end it. A live website can require hosting, domains, certificates, content delivery, backups, monitoring, form or email services, CMS licences, search, analytics governance, dependency updates, security response, accessibility fixes, browser testing, content support, and planned improvement. Build a twelve-month operating model with each provider, pricing unit, included allowance, forecast usage, renewal date, owner, and exit route. A low initial fee can create a high first-year total when essential services are omitted or tied to a supplier-controlled account.

Confirm practical ownership before work begins. Record who controls the domain, DNS, source repository, deployment account, hosting, CMS, analytics, consent tooling, form destination, third-party subscriptions, design files, content exports, and credentials. Specify whether the client receives source code, reusable components, editable design assets, documentation, training, and a working data export. Platform choice affects future cost when only one supplier can deploy changes or when moving content requires rebuilding it manually.

Support language should be measurable. Define the warranty boundary, supported browsers, response route, service hours, severity levels, backups, restoration responsibility, update policy, maintenance allowance, and how new scope is approved. Separate defect correction from content changes, optimisation, new features, provider price increases, and incident work. A promise of ‘ongoing support’ has little procurement value unless the proposal says what capacity exists, what is excluded, and what happens when the original team changes.

• Model twelve months of hosting, licences, provider usage, support, and maintenance
• Keep domains, repositories, deployment, CMS, analytics, and critical provider accounts under agreed control
• Require usable exports, documentation, credentials, and an exit handover
• Define warranty, support hours, response expectations, maintenance capacity, and change control

Compare agency proposals on one commercial worksheet

Give each supplier the same brief and require responses at a comparable level. Ask for phase objectives, deliverables, team roles, person-days or capacity assumptions, rates or commercial model, research and content responsibility, client dependencies, third-party costs, exclusions, contingency, feedback windows, milestones, acceptance evidence, intellectual-property terms, warranty, support, and change control. A fixed-fee supplier does not need to expose confidential salaries, but it should explain the release, assumptions, risk allocation, and events that would change the fee.

Normalise totals before deciding. Move optional features into a separate column; add omitted content, photography, licences, hosting, migration, analytics, security, accessibility, and operating costs; record internal client effort; and flag different ownership or support terms. Then score the proposals against understanding of the problem, solution fit, content method, migration safety, assurance evidence, team capability, operational ownership, and first-year total. CAP Code section 3 treats the manner in which a price is calculated as a price statement and requires clear, non-misleading qualifications, so the assumptions around any public or proposal figure should stay visible.[7]

Authorise work in evidence-led stages when uncertainty is material. A discovery can clarify the proposition and content model; a prototype can test a priority journey; a technical spike can test an integration; and a controlled release can prove the publishing and lead process. Tie every stage to a budget ceiling, reviewable outputs, decision, and exit criteria. Update the estimate when evidence changes the release instead of preserving an early number after its assumptions fail. No website budget can guarantee rankings, leads, or revenue, so commercial decisions should separate delivery scope from performance promises.

• Issue one common brief and proposal response template
• Compare like-for-like first-year totals rather than headline build fees
• Score content, migration, assurance, ownership, and team fit alongside cost
• Tie payments and continuation decisions to reviewable outputs and agreed gates
• Keep an approved change record showing cost, schedule, responsibility, and acceptance impact