How we propose

Most “proposals” are theater: a deck, a vague range, and a calendar invite. We write a short proposal that a technical buyer can actually use.

What is always in the doc

1. Problem in your words, restated so you can correct us early.
2. Constraints. NDA, local-first, latency, budget, stack preferences, who owns ops after ship.
3. Scope edges, what is in, what is explicitly out, and what would expand the price.
4. Approach, architecture notes at the level of decisions, not a 40-page design fiction.
5. Timeline and price, fixed when the edges are known; T&M cadence when they are not.
6. Risks, the two or three things most likely to bend the plan.

What is never in the doc

• Fake precision (“14.5 developer-days”) when discovery is incomplete.
• Logo walls of tools we will not actually use.
• Open-ended retainers disguised as fixed work.

If the proposal is wrong, you should be able to say so in one paragraph. That is the point, agreement before build, not surprise after invoice.