The longest proposal I ever sent was fourteen pages. It had a cover, a table of contents, a section on my “approach”, two case studies, and a pricing table on page eleven. The client’s entire reply was: “Thanks. What’s the total?”<\/p>\n
That was 2019. I’ve sent a lot of proposals since, and the ones that got signed were the short ones. The template I use now is two pages, sometimes three, and it opens with a section most developers leave out entirely. This post is that template, section by section, with the wording I use and the reasons I use it. Copy what’s useful. Argue with the rest.<\/p>\n
One thing before we start: a proposal isn’t a quote. A quote is a number. A proposal is the document that makes the number feel reasonable, and that’s a different job. If your proposals get answered with “what’s the total?”, the number isn’t the problem. The document around it is.<\/p>\n
The first section of my proposal has no heading about me. It’s headed with the client’s project name and it restates the problem they told me about on the discovery call, using their phrasing wherever I can.<\/p>\n
If they said “our checkout page loses people on mobile and we don’t know why”, that sentence goes in almost verbatim, followed by two or three lines about what I heard behind it. Something like: the team has no analytics on the checkout steps, the page was built in 2021 and hasn’t been touched, and the owner suspects the shipping calculator but hasn’t been able to prove it.<\/p>\n
I do this because it’s the section clients read first and read most carefully. They’re checking whether I understood them. Every proposal that’s been signed quickly had a client reply along the lines of “yes, exactly, that’s the problem”. Every proposal that went quiet was one where I’d rushed this part and described the project I wanted to build instead of the problem they had.<\/p>\n
It also fixes something for me. Writing their problem down in one paragraph is a test of whether I understood it. When I can’t write that paragraph, I don’t send the proposal. I book another call.<\/p>\n
This is the section that wins the job, and it’s the one I didn’t have for my first three years. My proposals listed what I’d build. They never said what I wouldn’t. And every project that went wrong went wrong in the gap between those two lists.<\/p>\n
Now the “Not included” section sits directly above the “What I’ll build” section. Higher on the page. That’s deliberate: a client skimming for surprises finds the boundaries before they find the promises.<\/p>\n
The wording is plain. For the checkout project, it read roughly like this:<\/p>\n
Not included in this proposal\n- Changes to the shipping calculator logic (we'll measure it first; fixing it is a separate quote)\n- Redesign of pages other than checkout and cart\n- Copywriting for the new checkout steps (I'll use your existing text)\n- App store or payment provider account setup\n- Ongoing hosting or maintenance after launch\n<\/code><\/pre>\nNobody has ever pushed back on this section. Not once. What happens instead is the client reads it and says “oh, we do want the shipping calculator fixed, can you add that?”, and now we’re having the scope conversation before the contract exists instead of in week four. I wrote about the “quick one” that cost me a week<\/a>, and the honest lesson from that was that the proposal had no boundary for the request to hit.<\/p>\nIf you take one thing from this post, take this section. It costs five minutes to write and it has saved me more money than any pricing trick.<\/p>\n
The build, in phases, with a price on each<\/h2>\n
Then the actual work. I break it into phases, and each phase gets its own line, its own deliverable, and its own price. Not hours. Not a day rate. A price for the outcome.<\/p>\n
For the checkout project, three phases: measure (add step-level analytics, two weeks of data, a short findings note), fix (the changes the data justifies, capped at a listed set), and verify (compare conversion for two weeks after launch, one summary). Each had a number next to it, and the total was the sum.<\/p>\n
Phasing does two things. It lets the client say yes to phase one without committing to everything, which lowers the risk of the first yes. And it gives me a natural place to stop if the relationship turns out badly. I’ve had two projects end after phase one, on good terms, because the data showed the problem wasn’t what anyone thought. Both clients came back later for other work. Neither would have if I’d sold them a single six-week build and then told them halfway through that the premise was wrong.<\/p>\n
I don’t include hourly estimates anywhere in the document. If I put “approximately 40 hours” next to a price, the client divides one by the other and now we’re negotiating my hourly rate instead of talking about their checkout. The price is the price. If they want to know how I got there, I’ll tell them on a call.<\/p>\n
Assumptions, and what I need from you<\/h2>\n
Two short sections, back to back. “Assumptions” is where I write down the things the price depends on: that I’ll have staging access by the start date, that the existing codebase runs locally with the README (I always check this before sending, and it’s wrong about a third of the time), that the client can approve designs within three working days.<\/p>\n
“What I need from you” is the same idea from the other direction. A named person who can make decisions. Access credentials by a date. Existing analytics exports, if they have them. Their brand assets in a usable format, which is a sentence I added after receiving a logo as a 240-pixel JPEG for the third time.<\/p>\n
I don’t write these to be defensive. Most delays on a client project are waiting, and most waiting is caused by something nobody wrote down. When the approval takes nine days instead of three, I don’t argue. I point at the line, we agree the timeline moves, and nobody feels ambushed.<\/p>\n
Payment terms that don’t need a lawyer<\/h2>\n
My terms are short. A deposit before work starts, the balance on launch, and a per-phase invoice on projects that run more than a month. The deposit is 40 percent. I’ve tried 50 and it made a couple of smaller clients hesitate; I’ve tried 25 and it made me the bank. Forty seems to be where nobody flinches.<\/p>\n
Invoices are due in 14 days. I state the late-payment terms in one line, and I don’t invent them. In the UK, the Late Payment of Commercial Debts (Interest) Act 1998<\/a> makes statutory interest an implied term of business-to-business contracts, so I reference it rather than negotiate a penalty. In New York City, the Freelance Isn’t Free Act<\/a> gives freelancers a legal right to a written contract and to timely, full payment, with double damages for violations, and the state has since extended similar protections. I’m not a lawyer and the rules where you are will differ. The point is that a lot of what you’d want in a payment clause already exists in law somewhere, and citing it reads as calmer than threatening it.<\/p>\nThe other line in this section is the validity date. The proposal is good for 14 days. After that I re-quote. I don’t do it for pressure. My availability changes, and I’ve been caught by a client accepting a three-month-old proposal for a slot I no longer had.<\/p>\n
The skeleton<\/h2>\n
Here’s the whole thing, headings only, in the order it appears. Mine lives in a plain document; the tool doesn’t matter.<\/p>\n
[Client name]: [Project name]\nProposal, [date]. Valid until [date + 14 days].\n\n1. The problem (their words, one paragraph)\n2. Not included\n3. What I'll build (phases, each with a deliverable and a price)\n4. Timeline (start date, phase dates, what moves if approvals slip)\n5. Assumptions\n6. What I need from you\n7. Price and payment terms\n8. Next step (one sentence: reply "yes" and I'll send the deposit invoice)\n<\/code><\/pre>\nTwo pages when the project is simple. Three when there are several phases. Never fourteen.<\/p>\n
Section eight matters more than it looks. The document ends by telling the client exactly what to do, and it’s one small action, not “let me know your thoughts”. Most of my signed proposals were accepted by a two-word email.<\/p>\n
What I’d change if I were starting again<\/h2>\n
I’d have written the “Not included” section from day one, obviously. But the bigger regret is that I treated proposals as sales documents when they’re really the first piece of project documentation. Every section above gets reused. The phases become the milestones. The assumptions become the first thing I check when something slips. The problem statement is what I read before the final demo to make sure I built what was asked for.<\/p>\n
Seen that way, the time spent on the proposal isn’t overhead. It’s the planning I’d have to do anyway, done before the money is committed instead of after.<\/p>\n