Writing proposals
"How we draft proposals that define exact scope and prevent disputes."
Why this exists
Vague proposals cause scope creep. We write proposals that read like technical specifications. They state exactly what we will build and what we won't. This keeps both sides aligned.
Operational Flow
Define the problem: State the client's core problem and the outcome they need.
Outline the scope: List every page, feature, and integration we will build.
Specify out-of-scope: Add a section detailing what we won't build under this deal.
Detail the timeline: Map milestones to week numbers, listing what we need from the client.
Include payment terms: Define milestone payments and invoice triggers.
What good looks like
- A proposal that defines database migrations down to tables and endpoints.
- The client signs without asking questions because everything is plain.
- Engineers read the proposal and know exactly what to build on day one.
What NOT to do
- Don't use template filler or jargon like 'cutting-edge solutions' or 'value delivery'.
- Don't make verbal promises. If it isn't in the proposal, it doesn't exist.
- Don't send a proposal without checking if engineers are free to hit the dates.
We used to write proposals filled with stock photos and marketing copy. We thought clients wanted to see our creativity, but they just skipped to the pricing page. One client told us he ignored the presentation and just wanted to know how we would fix their API bottleneck. That day, we threw out the marketing templates and started writing proposals that look like RFCs.
If you can’t explain a feature in two sentences, you don’t understand it well enough to scope it. Keep the language lean, state the constraints, and put the price next to the work. Let the technical details prove what we can do.