Prepared for TBD client name by TBD your company. This is the A4 starter: every page below is built from the same component vocabulary as the slide deck, laid out at 210 × 297 mm and printed one page per sheet.
Open with the recommendation, not the reasoning — a reader who stops after this page should still know what is being bought, what it costs, and when it lands. Everything after this is evidence for a decision already stated here.
Replace this paragraph with the shape of the engagement in the client's own words: the outcome they asked for, the constraint that makes it urgent, and the one thing you will do differently from the obvious approach. Two paragraphs at most — the detail has its own pages.
Prove you listened before you propose anything. Everything on this page should be traceable to something the client said, wrote, or published — no invented context, and nothing you can't point at a source for.
Anything on this page you can't source — a number, a date, a name — wears the TBD marker until the client confirms it: TBD confirm at kickoff.
A deliverable is something the client can receive, review, and accept. If a line here can't be handed over, it belongs in the approach on the next page, not in scope.
What it is, what format it arrives in, and what "done" means for it. Name the file, the system, or the document — not the activity that produces it.
Accepted when: TBD criterion
Accent variants sort deliverables into workstreams. Use one accent per stream — never one per card for decoration.
Accepted when: TBD criterion
Keep each card to three or four lines. A scope that needs a paragraph per line is a scope that hasn't been decided yet.
Accepted when: TBD criterion
Four accents is the ceiling. A scope needing a fifth workstream is a scope that wants splitting into two engagements.
Accepted when: TBD criterion
Anything the client asked about that isn't in this fee. Naming it here — unpriced — is how you keep it out of scope without saying no.
Quoted on request
Weekly written status, a named point of contact, and a handover pack at close. The tinted card is the one thing you most want read — at most one per page.
Each acceptance criterion is repeated in the schedule on page 6 and in the acceptance table on page 10 — three places, one wording. If they ever disagree, this page governs.
Phases exist so both sides can stop cleanly. Each one ends in something the client accepts and pays for, which is also what makes the schedule on the next page enforceable.
Phase durations are working weeks and stay TBD until a start date is agreed. The milestone dates on page 6 are derived from them — change one and the other follows.
Every row names an owner. A schedule where the client owns nothing is a schedule that slips quietly — the dependencies are the honest part of the table.
| Milestone | What lands | Owner | Date |
|---|---|---|---|
| Signature | This document accepted; phase one scheduled | Client | TBD |
| Kickoff | Access granted, assumptions confirmed | Both | TBD |
| Phase 1 close | Current state documented, measures agreed | Us | TBD |
| Midpoint review | Working deliverables reviewed in writing | Both | TBD |
| Phase 2 close | All deliverables submitted for acceptance | Us | TBD |
| Acceptance | Criteria signed off, handover session held | Client | TBD |
| Support ends | Thirty days after acceptance | Us | TBD |
Dates are working days from signature and assume the access listed on page 9 is granted within five days of kickoff. Every date above is a TBD until the start date is fixed.
Price the phases, not the hours — it is the only breakdown a client can act on. The highlighted row is the total; it is the number the reader is looking for, so let it be found.
| Phase | Basis | Payment | Fee |
|---|---|---|---|
| Phase 1 · Establish | Fixed fee | On signature | TBD |
| Phase 2 · Build | Fixed fee | On midpoint review | TBD |
| Phase 3 · Hand over | Fixed fee | On acceptance | TBD |
| Expenses | At cost, pre-approved over TBD | Monthly, in arrears | At cost |
| Total | Excluding tax and pre-approved expenses | Three milestones | TBD |
Fees are quoted in TBD currency, exclusive of tax, and valid for 30 days from the issue date on the cover. Payment terms: TBD days from invoice.
Name the people who will actually be on the engagement. A roster of roles with no names reads as a roster of people not yet hired.
Assumptions are the cheapest insurance in a proposal: every one you write down is a change request you don't argue about later. Exclusions are the same courtesy in reverse.
| Assumption | What happens instead |
|---|---|
| Access is late | Phase dates shift by the same number of working days; the fee holds |
| Material needs rework | Quoted as a change before any work starts on it |
| Scope grows | Priced against the day rate on page 7 and signed off in writing |
The signature block is the one component a proposal needs that a slide deck never does — ruled lines, a name, a role, a date. It lives in shared/paper.css as .sign.
| Accepting | Means |
|---|---|
| This document | The scope on page 4, the schedule on page 6, and the fee on page 7 |
| The assumptions | Everything listed on page 9, including what is excluded |
| First payment | TBD invoiced on signature; phase one scheduled within five working days |
Signed by both parties, this document and its assumptions are the whole agreement for the work described. Anything agreed later is added in writing and priced before it starts.
This page carries data-internal on its <section> tag, so node build.mjs starter-a4 --public drops it from the output entirely — and the build refuses to write the file if any internal page survives the strip.
| Internal line | Where it stands | Owner |
|---|---|---|
| Walk-away price | TBD — below this the phases don't pay for themselves | TBD |
| Softest estimate | Phase 2, if the access on page 9 lands late | TBD |
| Decision date | Chase on TBD if the signature block is still blank | TBD |
Both come from this file. Note where this page sits: last. Page numbers renumber themselves at load, so an internal page in the middle would shift every page after it — and every "see page 7" in the client's copy would point one page wrong. Keep internal pages at the end.