About scope: what's actually included
Problems in web projects are rarely bad faith: they're scopes that stayed implicit. Get in writing which pages the proposal covers, how many review rounds are included, and what's explicitly out.
A serious proposal can say 'this is not included' without flinching. Be more suspicious of the one that promises everything and details nothing.
About content: who writes and who loads it
The number one reason projects drag on for months isn't development: it's content that never arrives. Before signing, settle three things: who writes the copy, who sources the photos, and who migrates the content from your current site.
If the answer is 'you send it over', that's fine, but you need to know upfront: that work lands on your week, not the developer's. Also ask what happens to the timeline if content runs late.
About SEO and measurement: what comes standard
A new site should include by default the basics for Google to find it and for you to know whether it works. If anything on this list shows up as an 'extra', the proposal covers only part of the job.
- A unique title and description per page, not the same text repeated everywhere
- Redirects from your current site's URLs, so you don't lose what already ranks
- Sitemap and robots.txt configured, which is how Google crawls your site
- Analytics installed and verified: contact events actually firing, not just the snippet pasted in
- Structured data for your type of business, which helps Google and AI understand what you do
About ownership: whose name is on everything
This is the question most people skip and the one that costs the most in freedom: whose name ends up on the domain, the hosting and the code? I've seen businesses unable to touch their own site because the domain was registered to a provider they no longer spoke to.
The domain has to be in your name from day one, with you as the account holder. Same for hosting and code access. A good developer offers this without being asked; one who resists is telling you what the relationship will be like.
About the aftermath: who answers when something breaks
A site launches on a day, but it lives for years. Ask what happens next: whether there's a warranty period for bugs, who applies security updates, how fast they respond if something goes down, and whether you'll be able to edit content yourself or every change goes through them.
And the uncomfortable question that sorts everything out: how do I leave? If you ever want to switch providers, do you walk away with the complete, working site? The answer tells you whether you're hiring a service or entering a dependency.
Questions to bring to the meeting
- 01What exactly does the proposal include, and what's out?
- 02Who writes the copy and who sources the photos?
- 03Will the new site redirect the current URLs so Google rankings aren't lost?
- 04Are titles, descriptions, sitemap and verified analytics included, or extras?
- 05Whose name goes on the domain, the hosting and the code?
- 06Will I be able to edit content myself, or does every change go through you?
- 07What happens the day after launch: who updates and who answers if something breaks?
- 08If I ever want to switch providers, do I leave with the complete site?
Save this list and run it against your own site.