A fixed-price website package should make a project easier to buy, budget and manage. It should not make the important details disappear.
The phrase “fixed price” only has value when the outcome, scope, responsibilities and acceptance criteria are equally clear. Two proposals can carry the same headline price while offering very different levels of research, copy support, technical quality and post-launch care.
This guide explains what a credible UK website package should include, what is often excluded and how to compare quotes without reducing the decision to a feature count.
What does fixed price actually mean?
A genuine fixed-price proposal commits the supplier to deliver a defined scope for an agreed fee. It normally assumes that:
- the number and type of pages are known;
- the required integrations are listed;
- each party's responsibilities are explicit;
- review rounds and decision deadlines are defined;
- the content and asset process is agreed;
- the conditions that trigger a change request are documented.
It does not mean every future idea is included. If the brief changes from a lead-generation site to a member portal halfway through the project, the price and delivery plan should change too.
The best fixed-price packages remove uncertainty without pretending that change never happens.
The essential scope checklist
1. Discovery and success measures
The package should begin with more than a colour questionnaire. A useful discovery stage identifies the audiences, commercial priorities, key user journeys, proof points and constraints.
You should know what the website is expected to improve. That might be qualified enquiries, direct bookings, demo requests, applications or a reduction in repetitive support questions. Those outcomes should shape the architecture and measurement plan.
If discovery is not included, ask who is responsible for deciding the structure and how those decisions will be validated.
2. Information architecture
The proposal should list the pages or page templates being delivered. A ten-page website is not a helpful definition when nobody knows whether those pages are standard content pages, complex calculators or searchable directories.
Look for:
- an agreed sitemap;
- navigation and footer structure;
- priority conversion journeys;
- reusable content sections;
- redirects from old URLs where applicable.
A clear architecture also prevents late surprises about “extra” pages that were always necessary for the journey to work.
3. Content responsibilities
Copy is one of the most common sources of delay. The package should say whether the supplier will write, edit, migrate or simply upload content supplied by you.
Clarify:
- how many pages receive copywriting support;
- who interviews subject-matter experts;
- whether keyword and search-intent research is included;
- how many revision rounds apply;
- who supplies photography, case studies and legal text;
- whether old content is being migrated or rewritten.
“Content supplied by client” can be perfectly reasonable, but only when your team has the time, skills and internal approval route to deliver it.
4. Design and responsive behaviour
A package should explain whether you are receiving a tailored design system, a customised template or a lightly configured off-the-shelf theme. None is automatically wrong; the problem is paying for one while expecting another.
The design scope should cover mobile, tablet and desktop behaviour, not just a polished desktop homepage. It should also include practical states such as validation errors, empty search results, long headings and cookie banners.
Ask how accessibility, readability and keyboard use are considered during design. Retrofitting them after approval is slower and more expensive.
5. Build and content management
The technical scope should name the platform and what you will be able to edit. A usable content management system should let the right people update routine content without risking the layout.
Confirm whether the fee includes:
- reusable page components;
- forms and notifications;
- blog or resource publishing;
- redirects and 404 handling;
- cookie and consent configuration;
- analytics and conversion events;
- basic search-engine metadata controls;
- integration with named third-party systems.
If a feature depends on a paid service, the recurring licence should be shown separately.
6. Technical SEO and performance
No supplier can guarantee rankings, but the launch should not create avoidable technical barriers. The scope should cover page titles, descriptions, heading structure, canonical URLs, XML sitemap, robots instructions, redirects and indexability checks.
Performance work should include image treatment, font loading, script discipline and testing on representative mobile devices. A generic promise that a site will be “fast” is weaker than a stated test process and an explanation of which third-party tools may limit the result.
7. Quality assurance and launch
Ask what the supplier tests, on which browsers and who signs off the result. A sensible launch plan includes form delivery, link checks, analytics verification, privacy settings, redirect testing, backups and rollback steps.
The package should also say whether domain, DNS and hosting changes are included. Those are small lines in a proposal but critical parts of a safe launch.
8. Handover, ownership and support
You should know what you own at the end. Confirm ownership of design assets, copy, source code, domain, analytics accounts and third-party configurations. Ensure important accounts are registered in your organisation's name or provide your organisation with full administrative access.
Handover should include training and documentation proportionate to the system. Post-launch support should have a duration, response expectation and clear boundary between defect correction and new work.
Common exclusions to price separately
Fixed-price packages often exclude items that are genuinely variable. Typical examples include:
- domain and hosting renewals;
- premium fonts, plugins or stock imagery;
- extensive photography or video production;
- translation and multilingual content entry;
- complex CRM, booking or payment integrations;
- accessibility audits by an independent specialist;
- ongoing search optimisation and content production;
- major content migration or data cleansing;
- maintenance after the stated warranty period.
An exclusion is not a red flag when it is visible. Hidden assumptions are the danger.
Change control protects both sides
A good change process is not bureaucracy. It records the requested change, its effect on price and timing, and the decision before work begins.
The proposal should define what counts as a revision within scope and what counts as a new requirement. It should also provide a route for trading scope: for example, removing one integration to fund another without expanding the budget.
Agree who has authority to approve changes. Projects become expensive when several stakeholders can request additions but nobody owns the consequences.
How to compare website packages fairly
Create a one-page comparison based on outcomes and responsibilities, not just feature labels. For each supplier, record:
- The exact deliverables and page types.
- The amount of strategy, copy and content support.
- The design approach and number of review rounds.
- Named integrations and recurring third-party costs.
- Testing, launch and redirect responsibilities.
- Ownership, training, warranty and ongoing support.
- Assumptions that could create a later change request.
- Evidence that the team has delivered similar journeys.
Then assess the proposal against the commercial problem. A cheaper brochure site is not better value if the business needs qualified leads and nobody has designed the enquiry journey.
Our guide to briefing a web developer will help you give each supplier the same starting information. If you are deciding whether to publish package prices yourself, see should you show prices on your website?.
Red flags before you sign
Pause if the proposal:
- uses “unlimited revisions” without a decision process;
- promises a guaranteed Google position;
- leaves copy, migration and redirects unassigned;
- does not name the platform or recurring costs;
- relies on a theme or licence you cannot retain;
- has no testing or acceptance process;
- gives the supplier sole control of your domain or analytics;
- describes everything as bespoke without explaining what is actually tailored.
The bottom line
A strong fixed-price website package is a shared delivery agreement. It tells you what will exist, why it matters, who supplies each input and how both parties will handle change.
Buy the clarity, not the label. A precise scope makes price comparison fairer, protects delivery time and gives the finished website a much better chance of producing a commercial return.
If you want a transparent scope for a UK business website, explore our web development services or tell us what the website needs to achieve. We will make the deliverables, responsibilities and exclusions visible before the project starts.
