A good proposal and a bad one look similar at a glance. Both have a scope, a timeline, a price, and confident language. The difference shows up in about ten minutes of asking the right questions.

A good proposal and a bad one look similar at a glance. Both have a scope, a timeline, a price, and confident language. The difference is in what they’ve thought through — and it’s usually visible in about ten minutes of asking the right questions.

These apply to any proposal, including ours. We’d rather be asked them than not.

What’s explicitly not included?

The fastest way to tell a scoped proposal from an optimistic one is to ask what’s excluded. A proposal with no exclusions either covers everything — which is unlikely — or hasn’t thought carefully about the boundaries.

Watch specifically for content writing, photography, copywriting, integrations, and post-launch support. These are the items most often assumed rather than stated, and they’re where budgets quietly expand.

What happens when the scope changes?

Scope changes in almost every project, and the proposal should say what happens when it does. The answer you want is a defined process — a written estimate for the additional work, approved before it proceeds.

What you don’t want is ambiguity, an hourly rate that appears only after changes have been made, or a phrase like “we’ll work it out as we go.”

Where do the estimates come from?

Ask which parts of the timeline are based on similar work and which are assumptions. Good proposals distinguish between the two, because everyone who has done this before knows which parts are predictable and which aren’t.

A useful question

“Which part of this project are you least certain about?” Anyone experienced will answer honestly and specifically. Hesitation, or a claim that everything is straightforward, tells you something about how the project will go when it isn’t.

Who actually does the work?

Find out who you’ll be dealing with day to day, and whether that’s the same person who scoped the project. In some arrangements the person who sold the work is not the person who does it — and that gap is where expectations get lost.

If work is being subcontracted, it’s reasonable to know to whom, and to meet them.

What do we own at the end?

Ask plainly: whose is the code, the design files, the domain, and the hosting account? The right answer is unambiguous — you should own your own site and be able to take it elsewhere. Any hesitation here is worth taking seriously.

• You, or the agency, on the domain registration?
• Can you export your content if you leave?
• Is hosting in your name or theirs?
• Is there anything that would stop another developer picking this up?

What does the ongoing cost look like?

The build price is never the whole number. Ask what the site will cost to run and maintain in year two — hosting, licences, plugin subscriptions, and the ongoing work to keep it secure and current.

A cheap build with expensive ongoing costs isn’t cheap. Neither is a build whose platform requires constant paid attention to stay healthy.

How do we know it worked?

A proposal should say what success means in measurable terms. Not “increased engagement” — something you can look at afterwards and judge. Enquiries per month, time to load, conversion rate on a specific page, hours saved on a specific task.

If the proposal doesn’t define it, ask how it will be measured. If the answer is vague, the project will be judged on how it looks rather than what it does — and that’s a much harder thing to argue about later.

The proposal that answers the awkward questions up front is usually the one whose author has done this enough times to know where projects go wrong.

The short version

What’s excluded, what happens when things change, which estimates are assumptions, who does the work, what you own, what it costs to run, and how success is measured. Seven questions, and the answers say more about a proposal than the document itself.