How to write a web development proposal that gets signed
The proposal is not where you win the project. It is where you write down what you already learned. Most weak proposals are not badly written — they are badly researched, and no amount of formatting fixes that.
This is about the work around the document: what to ask before you write, how to turn a vague brief into something you can price, and what to do after you hit send. If you want the document structure itself, the web development proposal template has the nine sections laid out.
Step 1: Ask the five questions that set the price
A discovery call is not a requirements-gathering exercise. You are trying to find the things that will hurt later. These five do most of the work.
The single most useful question, and almost nobody asks it. If your contact cannot sign, you are not writing a proposal — you are writing their internal pitch deck. That changes what goes in it: more justification, less craft detail.
Separates a real deadline from an aspiration. "Our conference is on the 14th" is a constraint you can price urgency against. "Sometime in Q3" means the timeline will slip and it will not be your fault, but it will feel like it.
The most common cause of a stalled website project, and it costs nothing to ask. If the answer is a vague "we will sort it out", your timeline is fiction. Price the copywriting or name it as an exclusion — but decide now, not in week six.
You learn whether you are the first developer or the third. If someone was fired, find out why before you inherit the same expectations. This question has talked me out of more bad projects than any other.
If they cannot answer, the project has no definition of done, and "done" will drift toward whatever the loudest stakeholder feels on launch day. Push until you get something you could measure.
Step 2: Turn the brief into deliverables
Clients describe outcomes. You have to price nouns. The translation step is where proposals are won, and it is the part that gets skipped.
Here is the shape of it. A brief like this arrives constantly:
“We need a modern website that works on mobile and makes it easier for customers to get in touch. Our current one is really outdated.”
There is nothing to price there. Three words are doing all the damage: modern, easier, and outdated. None of them mean anything until you make them mean something:
| They said | You write |
|---|---|
| “modern website” | Five page templates (home, services, about, case study, contact), designed at three breakpoints |
| “works on mobile” | Tested on the two most recent versions of iOS Safari and Chrome on Android; WCAG 2.2 AA for colour contrast and keyboard nav |
| “easier to get in touch” | One contact form with spam protection, routing to a named inbox, plus click-to-call in the header |
| “outdated” | Migration of existing content into a CMS the client can edit; no rewriting of that copy (excluded) |
That last row is the one that saves you. “Outdated” very often means “the words are bad”, and the client is expecting you to fix that without ever saying so. Naming it as an exclusion in the proposal is a thirty-second job that prevents a month-long argument.
Step 3: Price the phases, not the hours
An hourly quote invites the client to audit your speed. The faster you are — which is to say, the more experienced — the less you earn, and the more you get asked why a page took six hours. Nobody wins that conversation.
Price by phase instead, with the hours visible as your working rather than as the product. The template has a full worked breakdown, but the principle is short: the client is buying a launched site, not 119 hours of your attention.
Give them a real choice while you are at it. A single number is a yes-or-no question. Two or three scoped options — a lean build, the recommended one, and a version with the extras they hinted at — turns it into “which one”. Same work for you, materially different conversation.
Step 4: Send it, then follow up on evidence
Send it while the call is still fresh — the same day if you can. Not because of any growth-hack reason, but because your understanding of what they said decays fast, and so does their enthusiasm.
Then the hard part. The follow-up email everyone sends — “just checking in!” — is weak because it contains no information. You are apologising for existing. If instead you know the proposal was opened twice yesterday and that someone spent four minutes on the pricing page, you can send a genuinely useful email: here is why phase two is priced the way it is, and here is what we could cut.
That is the whole reason proposal software for web development tracks engagement at all. If you are weighing tools, our honest PandaDoc comparison says plainly where we are not the right pick.
The shortest version
Ask who signs. Translate adjectives into nouns. Write down what you are not doing. Price phases, offer options, tie payments to milestones you control. Send it fast, and follow up with something worth reading.
None of that requires software. It requires being specific, which is harder and worth more.