Start with a business problem.
Ask what the website needs to change for the business. A clearer proposition? Better-qualified enquiries? A more usable product catalogue? The answer should shape the content, design and technology.
A proposal that opens with a platform, a template or a page count has skipped that step. Look for a short statement, in your own terms, of who the site is for and what those people need to do on it. If you cannot find one, you are being quoted for a format, not for a solution to your problem.
Make the work visible.
“A modern, responsive website” is an aspiration. You cannot review it, and you cannot tell when it is finished. A credible proposal names things you can check:
- Scope. The pages or templates, the features, and the integrations with systems you already use.
- Content. Who writes the words, who supplies photography, and who moves existing material across.
- Review points. When you see work, how many rounds of feedback are included, and who signs off.
- Acceptance criteria. The devices and browsers supported, the accessibility target, and how speed will be judged.
Content deserves particular attention. It is a common reason for a launch to slip, and the easiest line for a proposal to leave vague.
Separate the costs.
A single total hides the decisions inside it. Ask for the build, content, hosting, software subscriptions and ongoing support as separate lines, with one-off costs distinguished from recurring ones.
Then look for what is missing. Exclusions and assumptions are where budgets go wrong: third-party licences, stock imagery, copywriting, and the cost of changes once the scope is agreed. A proposal that explains how a change request is priced is more trustworthy than one that promises there will be none.
Protect what you already have.
If you are replacing an existing site, the proposal should say what happens to it. Pages that people and search engines already find need redirects to their new addresses. Enquiry forms, tracking and connected systems need to keep working on the day of the switch. Ask how the launch will be checked, and what happens if something has to be rolled back.
Plan beyond launch.
Ownership is the part most often left unsaid. Before you sign, confirm in writing:
- The domain name and hosting account are registered to your business, not to the agency.
- You receive the source files, and the licences for fonts, images and plugins are in your name or can be transferred to you.
- Your team has administrator access to the website and to any analytics or advertising accounts.
- Backups, documentation and training are included, with a defined period for fixing defects after launch.
A successful handover should leave you with a working website and a clear understanding of what comes next, whether or not you keep working with the people who built it.
Compare like with like.
The cheapest quote and the most detailed one are rarely describing the same job. Put them side by side and check that each covers the same scope, content and aftercare. Where one is silent, ask. How an agency answers a direct question about its own proposal tells you a good deal about how the project will run.
PivotAI perspective. General guidance; not a client case study or a substitute for specialist advice.