How We Write a Proposal You Can Hold Us To

A proposal is a contract that has not been argued about yet

Most proposals are marketing documents. They describe an outcome in appealing language, attach a number and leave the difficult parts to a conversation nobody plans to have. That works until week eight, when two people read the same sentence differently and both are right.

We write proposals as if the relationship will be tested, because occasionally it is. The test of a good one is simple: if we disagreed six months from now, would the document settle it?

What is in ours

• The problem, in your words. Written back to you so you can correct our understanding before it becomes expensive.
• What we will build. Specific enough to be checkable — screens, roles, integrations, states.
• What we will not build. Usually the longest section.
• Assumptions. Each one marked verified or unverified, with what changes if it is wrong.
• Price and payment schedule. Tied to milestones, not to dates.
• The change process. How a new requirement gets priced and approved, in three sentences.
• What you own. Code, data, infrastructure, accounts — all yours.

Why the exclusions section is the important one

Everyone reads the inclusions. Almost nobody reads the exclusions, which is where nearly all future disagreements live. Ours is explicit to the point of being slightly awkward: content population, third-party licence costs, training beyond the handover session, changes to systems we do not control.

The point is not to protect us from doing work. It is to make sure that if you need those things, they are budgeted rather than discovered. A client who learns in month three that data migration was never in the price has been failed by a document, not by a developer.

If an exclusions list is short, it is not because the project is simple. It is because someone decided the argument was cheaper later.

Assumptions, and what happens when one breaks

Every estimate rests on assumptions. Ours are listed, and each carries a note saying what happens if it turns out to be wrong — usually either “no material change” or “re-estimate this component”.

A typical example: we assume the existing customer export is complete and consistently formatted. If it is not — and roughly half the time it is not — we tell you in week one with a price for cleaning it, rather than quietly absorbing three weeks of data work and arriving late.

Milestones you can actually verify

Payment tied to dates rewards a supplier for the calendar passing. Payment tied to milestones rewards them for producing something. Ours are always the second, and every milestone is defined by something you can open and use.

1. Architecture and wireframes approved — you have read and signed off the documents
2. First working slice on staging — you can click it on your own device
3. Feature complete on staging — every item in the scope is demonstrable
4. Live, with handover documentation delivered

What we leave out on purpose

No hourly rate breakdown on fixed-price work. The number that matters is the total; an hourly figure invites a negotiation about our internal efficiency rather than about your outcome.

No technology name-dropping for its own sake. We name the stack and the reason, and that is all. A proposal that lists fourteen technologies is selling capability rather than describing a build.

No indefinite validity. Our prices hold for 30 days, because a quote from four months ago is a fiction on both sides.

Frequently asked questions