Fixed-Price Website Projects: What the Scope Should Specify

Define the deliverables and boundaries, not just the goal

A fixed-price website scope should state the agreed deliverables, what is outside the work, the assumptions both sides are relying on and how completion will be assessed. It should connect the business need to observable website requirements, rather than relying on an aspiration such as “improve the website”. A list of pages alone is not enough: it may leave unclear what users can do on those pages and what the supplier is expected to build.

Start by describing the outcome the business needs, then identify the website work that will contribute to it. For example, “make the website easier to use” does not say which users are struggling, what they need to do or how the work will be reviewed. A more useful requirement might describe a prospective customer finding a relevant service, reviewing the information needed to decide whether to enquire, and submitting an enquiry through a specified form. The scope can then identify the pages and form involved, the information the form collects, where the enquiry goes, and what will be checked during review.

For each requirement, record a decision that can be understood by both the business and supplier. Is the supplier creating a new page or updating an existing one? Does a form need to send information to an inbox, or to another system as well? Is the business supplying approved copy and images, or is content work included? If a point is undecided, mark it as a question to resolve before agreement rather than leaving it implicit.

Keep the scope focused on the work and its boundaries. It need not predict every later discussion or specify every visual detail at the outset. It should, however, make clear enough what is being delivered, what the buyer needs to provide, what has been assumed, and what would need separate agreement if requirements change. That gives both parties a reference for reviewing the work and identifying omissions.

Scope definition is separate from how a supplier calculates its price or which pricing model the business chooses. This section is about making the proposed work understandable and assessable, not ranking proposals. The following checklist can help turn that shared understanding into specific decisions about pages, functions, responsibilities and delivery.

Describe the outcomes and website journeys users need

Describe what each important user group must be able to do on the website, and what should happen as a result. This gives the supplier a basis for proposing a solution and gives both parties something observable to assess, without prematurely locking the scope to a particular technical approach.

Start by naming the user groups and the business tasks the website should support. For example, a prospective customer may need to compare services and make an enquiry; an existing customer may need to find guidance or request a booking. Record which tasks matter most, and what a successful outcome looks like to the business: an enquiry reaching the right team with enough information to respond, for instance, rather than simply a form being present.

For each priority journey, write down:

• Starting point: Where might the user arrive, and what information or prompt should help them choose the next step?
• Information needed: What must the user be able to find, or provide, to complete the task? Note any choices or details the business needs to route a request.
• Action and response: What does the user do, and what confirmation or useful next step should follow? For an enquiry, decide who receives it and what the user sees after submission.
• Exceptions: What should happen if required information is missing, a request cannot be submitted, or the user needs a route other than the main call to action?

Keep the scope focused on behaviour and outcomes. “Users can request a booking and receive confirmation of the next step” is more useful than naming a particular form tool or prescribing how the supplier must build it, unless that choice reflects a real business requirement. If different user groups need different routes, specify what distinguishes them and where each route should lead.

Before approving the scope, check that each priority journey has a defined starting point, user action, expected response and business outcome. If any of these is undecided, record it as a question for the buyer and supplier to resolve; otherwise a broad goal such as “generate more enquiries” can leave both sides with different expectations of what the fixed price covers.

Specify page types, design work and content responsibilities

Write down the page set the price covers, rather than relying on a broad phrase such as “pages as required”. For each page, record its name and whether it needs a distinct layout or can use a shared page type. Include quantities where they are known, and explain how the final set will be confirmed if it is not yet settled.

For example, replace “pages as required” with an agreed list such as a home page, a service overview and individual service pages, stating how many individual pages are included and which use the same layout. If the service list is still changing, make that an open decision: who will confirm it, by when in the project, and how additions after confirmation will be handled. This avoids leaving the supplier to guess whether a new page is a content variation or extra design and build work.

Describe the design work as deliverables and decisions. Record whether the scope includes page structure or wireframes, visual design for each distinct page type, responsive layouts, and any design elements specific to the business. Identify what the supplier will present for review, who on your side can approve it, and what approval means. If you agree review stages or limits on rounds of feedback, state them plainly; do not assume either party has the same idea of what a “revision” includes.

Assign content tasks page by page or by content type. For each, state who writes the text, supplies images and other materials, checks accuracy, and gives final approval. Specify any required format or preparation, such as supplying approved copy in a shared document or providing images selected and cleared for use by your business. Clarify whether the supplier is expected to enter supplied content into the website, edit it, select images, or create content. These are different tasks and should not be left implicit.

Also record what happens when the supplied material is late, incomplete or changes after approval. State whether the supplier will wait, use agreed temporary content, or proceed with another part of the work, and how a substantial rewrite or extra page will be assessed. Do not treat an unanswered content or design decision as included by default: list it as an open question, name the person responsible for resolving it, and agree when it must be settled.

Record integrations, data, migration and technical dependencies

For each connection to another system, name the system and describe what information must move, in which direction, and what should happen next. For example, if a visitor submits an enquiry, specify which fields should reach the customer relationship system, whether the website should show a confirmation, and who needs to be notified. “Connect to our system” leaves the supplier to guess which records, actions and responses are included.

Record how each connection is expected to work and what the supplier can rely on. Is there existing documentation, an agreed interface or a supplier who must enable access? Note who will provide credentials, technical contacts, documentation and test accounts, and by when. If another supplier must approve access or make a change, identify that dependency and what happens if it is not ready. Avoid assuming a particular connection method until the relevant systems and their capabilities have been checked.

For migration, define exactly what is moving: for example, named content types, files, product records or customer information. State who will provide the source material, how it will be supplied, and the condition or format it needs to be in. Clarify whether the supplier is transferring material as provided, restructuring it, correcting it or entering it into new pages. These are different tasks. Agree how the migrated work will be checked, such as comparing a sample of records or confirming that agreed pages and files are present, and who will resolve missing or inconsistent source information.

Describe the technical environment the project must fit. Record existing hosting, domain and account arrangements, who controls them, and whether the website must work with any systems already in use. Identify decisions still needed, such as where the site will run or who will manage access. Do not assume that a supplier can take over an account or change a setup without the buyer’s approval and the necessary access.

List data-handling questions that need an explicit decision or review by an appropriate specialist. Depending on the information involved, clarify what the website collects, where it needs to go, who needs access and what the buyer expects to happen to it. The scope should record unresolved questions rather than silently treat them as included work.

Before agreeing a fixed price, ask the supplier to identify what has been inspected and what remains unknown. Define how discoveries—such as inaccessible systems, incomplete records or a migration source in a different format—will be assessed and agreed before additional work proceeds. That gives both parties a boundary for the work without pretending every technical dependency is already understood.

Set out what the buyer and supplier each need to provide

For each piece of work, state what the supplier will provide and what the buyer must provide for it to proceed. Use the scope to assign essential tasks explicitly, rather than leaving them unassigned.

Record the buyer-side inputs that apply to this project: for example, access to the current website or relevant systems, answers from subject-matter experts, decisions about priorities, and approval of proposed work. Name the person responsible for each input. If more than one person contributes, identify who gathers their comments and gives the supplier the agreed response.

Set out the supplier’s outputs at the same level of clarity. For each deliverable, specify who prepares it, who presents it for review and who addresses feedback. Avoid relying on a general statement that the supplier will work with the buyer; say what each party is expected to do.

Connect inputs and decisions to the work that depends on them. For example, note that access is needed before the supplier can assess an existing system, or that an approved page structure is needed before relevant content is prepared. This need not imply a fixed project duration: it should make clear which decision or input is needed before the next activity can proceed.

Agree how decisions and feedback will be communicated. Name the buyer’s approver, state whether feedback should be consolidated, and specify how the supplier will be told that a deliverable is approved or needs changes. If several stakeholders can comment, clarify whose decision is final so conflicting instructions do not leave work unresolved.

Finally, write down what happens if an input is late, incomplete or changes after work has begun. The scope should say how the parties will discuss the effect on the work and agree any change before proceeding, rather than leaving the supplier to guess whether to absorb it. Check each dependency against an owner and ask the supplier to confirm any assumed buyer contribution that is not yet assigned.

Agree how the website will be reviewed and accepted

Write down how the buyer will check the website against the agreed scope, who will review it and how the supplier will receive feedback. Acceptance should depend on whether the stated requirements have been met, not on a broad judgement that the site is “good enough”.

For each priority journey, page type and function, specify what the reviewer will inspect and what evidence will help them decide. For example, a demonstration could show a user completing an enquiry journey and the resulting information reaching the agreed destination. For a page template, identify the agreed elements to check, such as its layout, content fields and behaviour on the agreed devices or screen sizes. Keep the checks tied to requirements already written into the scope.

Set out the review route: name who can approve on the buyer’s behalf, how they will gather feedback from other reviewers, and how they will send one consolidated response. Record how long the review period is intended to be, how comments should identify the affected requirement, and what happens if feedback is late, contradictory or unclear. Agree how disputed items will be discussed and who will decide whether the scope has been met. Do not leave either party to infer acceptance from silence or an informal conversation.

Agree a simple way to classify and track findings. A defect is a failure to meet an agreed requirement; a request for a new feature, changed behaviour or additional content is a proposed change to scope. Ask the reviewer to describe what they expected, what happened instead and where they saw it. The supplier can then respond against the relevant requirement. State how defects will be corrected and rechecked, and how out-of-scope requests will be assessed and approved before work proceeds.

If accessibility conformance is required, name the standard and level in the scope, along with how the agreed requirement will be assessed. Avoid relying on an undefined phrase such as “fully accessible”.

Before approval, check that every acceptance test has a corresponding requirement, that the buyer knows who will review it, and that both parties understand what happens to findings. If an item cannot be judged from the scope as written, clarify it before agreeing the project.

Make assumptions, exclusions and changes explicit

A fixed-price proposal is easier to assess when the agreed scope makes clear which work it covers. Ask the supplier to record the assumptions behind the proposal, name what is excluded, and explain how either party should handle an assumption that proves wrong or a requirement that was missed.

For each assumption, make the practical consequence visible. For example, record whether the price depends on the business supplying approved copy, whether an existing system can provide the required access, or whether the current website’s content can be transferred in the expected format. If the answer is not yet known, note who will investigate it, when a decision is needed and what happens if the answer changes the planned work.

List exclusions in terms the people doing the work can recognise. Identify assets or information the buyer must supply, tasks that are not part of the deliverables, and any work that would need separate agreement. Avoid relying on a broad phrase such as “content by client” without clarifying whether that means writing, editing, image selection, uploading or approval. Check that exclusions do not contradict the agreed outcomes or leave a necessary task without an owner.

Agree a change process before work begins. The scope should say who can raise a change, where it is recorded and what information is needed to assess it. A useful change request describes the requested result, why it is needed, and which existing requirement or deliverable it affects. The supplier can then explain the implications for deliverables, responsibilities and the project arrangement; the buyer can decide whether to approve, defer or decline it. Do not treat a change as included until both sides have agreed how it will be handled.

When a new issue appears, compare it with the agreed requirement rather than labelling it automatically as either a defect or extra work. A failure to meet a recorded requirement should follow the agreed review and findings process. A new preference, newly discovered requirement or change to an assumption may need the change process. If the scope does not say how to distinguish these cases, ask for that distinction to be written down before approval.

Before signing off, check that every important assumption has an owner and consequence, every exclusion is understood, and there is a clear route for recording and approving changes. Where the answer remains uncertain, write it as an open question with a named decision-maker rather than leaving it implicit.

Specify launch, handover and any post-launch support

Define what “ready to launch” means in practical terms, then list the launch tasks included in the project. For each task, name the person responsible and the input or approval they need. This could cover preparing the live hosting environment, connecting the agreed domain, moving the approved website into use, checking key journeys on the live site and confirming who gives final sign-off. Make clear which access details the buyer must provide and when.

Record what happens if a launch check finds a problem. Who reports it, where is it recorded, and who decides whether it prevents launch or can be addressed afterwards? Tie this to the agreed acceptance process so a concern is not treated as resolved simply because the site has been published.

Specify the handover materials the buyer will receive. For example, decide whether the supplier will provide administrator access, instructions for routine updates, relevant configuration details and a record of any services or accounts the buyer needs to manage. Clarify whether handover includes a walkthrough, who should attend and what the buyer is expected to be able to do afterwards. Confirm that access is transferred through an agreed, secure process rather than left with only one party.

State plainly whether post-launch support or maintenance is part of the fixed-price project. If it is, define its scope: what types of issue or task are covered, how the buyer raises them, who receives the request and how the supplier will report what falls outside the agreed support. Avoid relying on a vague promise of help after launch.

If ongoing support is excluded, record that boundary and identify what the buyer must arrange separately, such as responsibility for hosting, website updates, backups or technical maintenance. The scope should leave the buyer knowing who to contact when something needs attention and which arrangements must be in place before the supplier’s project work ends.

Use this checklist to find scope gaps before approval

Before approving a fixed-price website scope, use this checklist to record the decision, boundary or unanswered question for each area. A topic being mentioned is not enough: the scope should make clear what is included and how completion will be assessed.

• Outcomes: What should each priority user be able to do? Record the observable result that would show the requirement is met, such as a completed enquiry being received with the agreed information.
• Pages and content: List the included page types and quantities, including any shared layouts. Who writes, supplies, enters and approves the content? How will additional pages or substantial edits be handled?
• Functions: Name each required journey and action. What information does the user provide, what response should the website give, and what should happen next? Identify any unresolved behaviour or decision.
• Integrations and migration: Name each system or content source involved. Specify what data or content moves, what does not, who provides access and inputs, and who resolves any gaps or compatibility questions.
• Responsibilities: Assign an owner to each buyer input, supplier deliverable, decision and approval. Record when each is needed and what happens if an input or decision is delayed or changes.
• Assumptions and exclusions: Write down what the supplier is assuming, what is specifically outside the agreed work, and which points remain unanswered. For each open point, name who will resolve it and whether the scope or price needs confirming first.
• Review and acceptance: How will each requirement be checked against the agreed scope? Name who reviews the work, how they provide findings, and how the parties will distinguish a defect from a request for additional work.
• Change handling: Who can propose a change, how will it be recorded, and who must agree its effect on deliverables, cost or timing before work proceeds? Record the approval route rather than relying on informal conversations.
• Launch, handover and support: List the launch tasks and checks, who performs them, and what access, documentation or other handover materials the buyer receives. State whether post-launch support is included, what it covers, or whether it must be arranged separately.

Mark each item as agreed, excluded or awaiting an answer. Resolve material assumptions and unanswered decisions before approval; otherwise, both parties may be working from different expectations about what the fixed price covers.