In short
A proposal wins when the client recognises their own problem described more clearly than they described it, and can see a credible route from it to a result. Lead with the restated problem, be specific about scope and what is excluded, present price as a consequence of scope rather than a number to negotiate, and keep it short enough to be read by someone who is not technical.
What a proposal actually has to do
The client is deciding between you and one or two alternatives, and they cannot evaluate the work itself — that is why they are hiring.
So they evaluate the proxy available to them: who seems to understand the problem best. Everything else — process descriptions, tool lists, team bios — is secondary to that judgement.
Which means the most valuable page in your proposal is the one describing their situation back to them.
Lead with the problem, restated
Open by describing what they told you, sharpened.
Not repeated verbatim, and not translated into your vocabulary — clarified. Name the constraint they mentioned in passing. Connect two things they said separately. Identify the cost of the current situation in their terms.
When a client reads their own problem stated more precisely than they managed, two things happen. They trust your judgement, because you demonstrated it rather than claimed it. And every subsequent recommendation is read as following from a shared understanding.
If you cannot write that section well, you did not learn enough in the conversation, and no amount of process description compensates.
Be specific about scope
Vague scope produces vague projects and difficult conversations later.
Say what is included, concretely. Not "website design and development" but the pages, the templates, the responsive breakpoints, the CMS, the integrations, the number of revision rounds.
Say what is not included, explicitly. Content writing, photography, ongoing maintenance, third-party licences, hosting. Naming exclusions is not defensive; it prevents the assumption that produces an awkward conversation in week six — and it is the single most effective control on scope creep.
Say what you need from them, with dates. Content, approvals, access, a named decision-maker. Most delayed projects are delayed on the client side, and a proposal that never asked for anything cannot fairly raise it later.
Structure the price so it is not just a number
A single figure invites one question: can it be lower?
Breaking it down changes the conversation from is this too much to what do we want.
Break by phase or workstream — discovery, design, build, launch — so the client sees what they are buying at each stage.
Offer options, not discounts. Two or three scopes at different prices lets someone choose rather than negotiate. A smaller scope at a lower price is a legitimate choice; the same scope at a lower price devalues the work and tells them the first number was arbitrary.
Name what changes the price, so a later change order is expected rather than a surprise.
On fixed price versus time and materials: fixed price suits well-defined work and puts estimation risk on you, which is why it should carry a margin for that risk. Time and materials suits genuinely exploratory work and needs a trust level the client may not yet have. For most first engagements, a fixed-price discovery phase followed by a scoped build is the arrangement that works for both sides.
Show relevant evidence, briefly
One or two pieces of work resembling their problem, with the outcome stated in numbers.
Relevance beats prestige. A small project in their sector persuades more than a large one in an unrelated field.
Link to full case studies rather than inlining them. A proposal is not a portfolio, and length dilutes the parts that matter.
Make the next step obvious and small
End with one clear action, sized to the client's current level of commitment. "Reply to confirm and we will send the agreement" or "book a call to walk through it" — not a menu of options.
Include a validity date. It is standard, it is honest about capacity, and it gently prevents a proposal from being decided six months later against prices that have moved.
What to leave out
Long company histories. Nobody hires on founding date.
Generic process descriptions. "We start with discovery" appears in every proposal they will read.
Tool lists. Irrelevant to the buyer, and it dates the document.
Terms and conditions in the body. Attach them; do not make the reader wade through them to reach the price.
Anything you would not defend in a meeting. If a line exists because it sounds impressive, remove it.
Length and readability
Short enough to be read fully, which usually means a few pages. Long proposals get skimmed, and the parts that get skimmed are the parts you spent longest on.
Write for the person who will decide, who may not be technical. If the decision needs sign-off from someone who never met you, the document has to carry the argument alone.
And open with a summary — problem, approach, price, timeline — in a few sentences. Some readers will read only that, and it should be enough to say yes.
If you are putting together a proposal for something significant and want it read before it goes out, book a call.
Common questions
What should a project proposal include?
A restatement of the client's problem, sharpened; a specific scope with explicit exclusions; what you need from them and by when; a price broken down by phase or option; one or two relevant pieces of evidence with real outcomes; and a single clear next step. Open with a summary that could stand alone.
How long should a proposal be?
Short enough to be read in full, usually a few pages. Long proposals get skimmed, and the sections you spent longest on are the ones that get skipped. Lead with a summary covering problem, approach, price and timeline, since some readers will read only that.
Should I include the price in the proposal?
Yes, and structured rather than as one figure — a single number invites the question of whether it could be lower. Break it by phase or offer two or three scope options, so the conversation becomes what to buy rather than what to discount.
Should proposals list what is excluded?
Yes, explicitly. Naming exclusions such as content writing, photography, hosting, or third-party licences is not defensive — it prevents the assumption that produces an awkward conversation weeks in, and it is the most effective single control on scope creep.
Is fixed price or time and materials better?
Fixed price suits well-defined work and places estimation risk on you, so it should carry margin for that. Time and materials suits genuinely exploratory work but needs trust a new client may not have yet. For a first engagement, a fixed-price discovery followed by a scoped build usually works for both sides.
