What should a website creation proposal include?

A website creation proposal should answer a straightforward question: what exactly will you receive, under which conditions and with what contribution from your team? A price, a date and the phrase “custom website” are not enough to describe the expected work.

For a high-end project, the precision of the proposal matters as much as the quality of the initial presentation. It helps preserve priorities, organise decisions and recognise new requests when they arise. The following review framework helps you identify operational commitments and points that remain implicit.

A project summary that reflects your actual need

The opening should identify your business, the website’s main objective and the priority audiences. Check that the description reflects your discussions. A very general statement can conceal a difference in expectations: you want qualified project enquiries, while the proposal primarily provides a presentation gallery.

The summary should also distinguish a new website from a redesign. For a redesign, identify what must be retained: content, service pages, enquiry workflows or multilingual organisation. A new appearance alone does not describe the transition from the existing site.

Ask for important limits to be recorded. A property presentation is not automatically a booking engine. An online shop does not necessarily include every operational connection you have discussed. It is better to identify that distinction before approving the budget.

A page list separating templates and content

The proposal should list the types of pages and the amount of content population included. A homepage, a service page and a project detail page have different structures. Several projects may then use the same template.

Request a concrete example of what will be delivered. “Portfolio” can mean a grid alone or a combination of grid, filters and detailed pages. “Blog” can cover a listing page without including the writing of any articles. A feature name should not replace its description.

Specify useful variations, such as a page without photography, a longer text or a gallery with different image formats. You do not need to anticipate every imaginable possibility. The ordinary situations within your business should nevertheless remain manageable.

Content assigned to an identified person

For each content family, establish who provides information, who produces the final material and who approves it. This prevents the agency from waiting for your copy while your team assumes somebody else is writing it.

Quantities should be explicit wherever they affect the work: project entries to migrate, languages to populate or pages to write. If materials will arrive later, explain the effect on scheduling and on the usefulness of the initial version.

Ask how missing information will be raised. A named contact and a consolidated list of questions are often enough. What matters is that incomplete content becomes a visible decision rather than an assumption that silently travels into the published website.

A clear description of visual design

The proposal should explain what will be designed: art direction, main screens, mobile versions and particular interface states. Ask how the work will be presented and at which stages you can contribute.

A moodboard is a collection of visual references; it is not a complete page design. A mock-up shows more of the structure, copy and components. An interactive prototype may let you move between selected screens without being the finished website. These deliverables have different purposes.

If you expect animation, ask how its pace and operation will be approved. Still images do not always explain an effect controlled by scrolling. Depending on the project, the proposal may include a focused demonstration or a described sequence. The chosen deliverable should help you assess the actual experience you are buying.

Functions described through their use

Each significant function should specify what visitors do and what your team receives. As a fictional illustration, a consultancy’s project form might collect a need, a target date and contact details before sending the enquiry to an identified address.

Distinguish that agreed function from additions that have not yet been planned. Automatic qualification, distribution between several people or creation of an entry in a sales tool can be separate requirements. They do not follow automatically from the word “form”.

Also ask which operating situations will be checked: incomplete messages, invalid entries, successful submission and failed delivery. For reservations, specify whether visitors make a request or obtain a confirmation. That distinction changes what the interface can accurately tell them.

Tools and dependencies made visible

When the project relies on an external service, the proposal should explain its role and any assumptions that still need confirmation. The agency should be able to say who holds the account, who supplies access and when the connection will be verified.

Avoid technology lists that do not relate to your uses. You primarily need to understand where content lives, where enquiries arrive and how staff intervene. A readable explanation makes dependencies visible without requiring you to become a developer.

If a function depends on a capability that has not been confirmed, request a verification step and a planned decision if it proves unavailable. A quote may contain an assumption. That assumption should be visible and distinct from an established commitment.

A schedule built around approval stages

A final date alone is not a project schedule. Look for milestones: discovery, content receipt, art direction approval, development, checks and publication. Each stage should have a responsible person and a condition for moving to the next one.

The proposal should state what it expects from you. An agency can prepare work within an agreed period, but cannot approve your business information on your behalf. Plan for the availability of the people whose input is essential.

Ask what happens if content arrives after the intended date or a decision changes an already approved stage. The aim is to understand how the schedule will be reconsidered and communicated. A delay should lead to an explicit revised plan, rather than different assumptions about the same launch date.

A framework for feedback and new requests

Discussion is part of design. The proposal should still explain how it is organised: consolidated feedback, a main contact, the deliverables concerned and the number of rounds or another stated boundary.

A copy correction, a detail adjustment and a new page are different types of change. Ask how they will be distinguished. A request that transforms an approved journey should come with an explanation of its consequences before additional work starts.

Within your team, centralise comments in a shared document and identify the decision needed. Contradictory or scattered messages make approval harder. This process is part of your preparation too, even when the agency coordinates the exchanges.

Where several people must contribute, separate factual checks from design preferences. An operations manager may need to confirm the enquiry process, while a marketing lead approves the message hierarchy. Naming those responsibilities helps the final decision reflect the right expertise.

Checks before publication

Look for a description of planned checks. They should correspond to real uses: navigation, content, forms, display on target devices, internal links and page administration. A visual review alone does not show whether enquiries reach the intended destination.

The person approving the site should know what to test and how to report a problem. A checklist and a shared tracking space may be sufficient for a straightforward project. The important distinction is between issues to fix and improvements newly requested.

Then clarify the publication procedure and the checks immediately afterwards. They should concern the version available to visitors, rather than only a demonstration reviewed several days earlier. Establish who can respond if an essential journey needs correction after launch.

A handover that supports continuity

The proposal should list the access and materials to be transferred, together with their recipient. Ask where domain, hosting and content management accounts will be held when those elements form part of the arrangement. Clarify what can be recovered if you later change providers.

Training deserves its own description: format or duration, participants and covered tasks. A general presentation may not be enough if staff will regularly publish projects or maintain several languages. Prefer a handover centred on those specific operations.

Distinguish delivery corrections, assistance and maintenance. These terms can involve different commitments. Ask which tasks are included and how they are organised, without assuming that an accompanying support period automatically includes every future improvement.

Request a practical handover example. If someone publishes a new project during training, you can see whether images, text and language versions are understandable to the team. That is more informative than merely knowing that a tutorial document will be supplied.

A readable price with expenses separated

The document should make the accepted scope, optional work and recurring expenses understandable. Ensure you compare amounts presented on the same basis, and clarify applicable tax treatment with the appropriate people where needed.

For external subscriptions, identify who pays and how often. For options, ask whether they can be added independently or whether they alter the project structure. A small unexplained item can be significant if an essential function depends on it.

Payment stages should be understandable in relation to the work. If wording is ambiguous, have it clarified in the documents before committing, rather than relying solely on a spoken explanation. Keep the agreed version accessible to everyone responsible for approval.

The final review before your agreement

Read the proposal with someone who did not attend the meetings. Can they explain the pages being delivered, the content still required, the agreed functions and the approval process? Their questions will reveal areas that remain implicit.

A useful proposal does not have to become an unreadable document. It should turn expectations into identifiable work. To prepare a clear enquiry, discuss with MV Design the deliverables, responsibilities and publication conditions that matter for your business.