What a good proposal for digital work contains
A proposal is a promise you can hold someone to. The eleven sections a serious one has, the two most often missing, and how to compare them.
The short answer
A proposal is a promise in writing, and a good one lets you hold the supplier to it. It tells you what problem is being solved, exactly what you get and what you do not, how the work will run, what it costs and when you pay, what has been assumed, what happens when something changes, who owns the result, and what happens after launch. Eleven sections. The two that go missing on the other side of a client’s desk are scope out and ownership, and those two absences are where the disputes begin.
The eleven sections
| Section | What it should say | If it is missing |
|---|---|---|
| 1. Your problem, restated | The supplier’s understanding of what you need and why | They may be selling what they have, not solving what you asked |
| 2. Scope in | Every page, feature, integration and deliverable, specifically | Everything is arguable later |
| 3. Scope out | What is explicitly not included: content writing, photography, migration, training, ongoing support | The most common source of disputes |
| 4. Deliverables | What you receive, in what form: code in your repository, designs, documentation, accounts | You may receive a live site and nothing else |
| 5. Approach and stages | How the work runs: discovery, design, build, test, launch; what you approve at each gate | No moment to steer before it is too late |
| 6. Timeline | Stages with dates or durations, and what depends on you | Delays with no accountable cause |
| 7. Price and payment terms | Fixed price or capped estimate; what triggers each payment | Surprises at invoice time |
| 8. Assumptions | What the price depends on: content ready by a date, one round of revisions, existing brand assets | Every assumption that fails becomes a change request |
| 9. Change process | How changes are requested, priced and approved | Scope creep with no control, in either direction |
| 10. Ownership and hand-over | Code, designs, accounts, domains and data in your name; what hand-over includes | You may not own what you paid for |
| 11. After launch | Warranty period, maintenance options, response times, what is included and what costs extra | The site goes live and the relationship goes silent |
The two most often missing
- Scope out. Content, images, migration, translations, training, hosting, ongoing maintenance: every project needs them and every proposal that omits them ends in “we assumed that was included”. Ask for the list.
- Ownership. Whose name is on the domain, the hosting, the repository, the analytics? What is delivered at hand-over? If the proposal does not say, the default in practice is that the supplier holds it. Ask for it in writing.
Comparing proposals fairly
Different suppliers structure proposals differently, so compare the inclusions rather than the totals: discovery, content, testing, accessibility, training, aftercare, and the number of revision rounds. A lower price with a shorter list is not a lower price. Rewrite each proposal into the eleven headings yourself. Where a heading is empty, ask the supplier before deciding. Then compare prices for the same scope, with the same ownership and the same after-launch terms. The gaps that appear in that exercise are the real difference in price: what one proposal includes and another leaves for later is worth more than the figure on the last page.
What this means for you
Before signing anything, check the proposal against the eleven sections. Insist on scope out and ownership in writing; those two protect you more than any other clause. Compare proposals on the same structure, and treat empty sections as questions, not savings. A proposal that answers all eleven is a promise you can hold someone to. One that does not is a hope with a price on it.
Frequently asked questions
Is a short proposal a bad sign?
Not necessarily. A short proposal that covers the eleven points precisely beats a long one full of boilerplate. What matters is whether the questions are answered: what exactly is included and excluded, what it costs, who owns the result, and what happens when something changes. Length is not the measure; completeness is.
The proposal says the price is an estimate. Is that acceptable?
For discovery and research, an estimate with a cap is reasonable, because the work is defining the scope. For a build with a defined scope, ask for a fixed price with a written change process. An open estimate for defined work moves all the risk to you.
What if the proposals we received are structured completely differently?
Rewrite each into the same eleven headings yourself. It takes an hour and it is the only fair comparison. Where a proposal has nothing under a heading, that is a question to ask the supplier before deciding, not an assumption to make in their favour.