How to Write a Project Proposal When the Price Is Fixed and the Scope Isn't

Start with the objective and what “done” looks like

The first project-specific move is to separate three things the standard proposal structure treats as one: why the project exists, what it produces, and how both sides know it is finished. The objective is the client’s reason for spending the money, in their words; the deliverables are the artifacts your work produces. The third one is what proposals skip: the success criteria, the agreed test that says the project is complete and the final payment is due. Detail the deliverables and leave the other two implied, and you have priced activity instead of a finished project. The section order and overall format are a separate subject, covered in our guide to proposal formats; for ongoing retainer or marketing work, which scopes differently, see our guide to writing a marketing proposal.

A deliverables list with no definition of done leaves the most expensive question (when is this over) open. “A redesigned website” is a deliverable, not a finish line. Nothing in those two words says whether done means the new design is live on staging, live in production, live with the client’s content loaded, or live with their team trained to update it. Each is a different amount of work, and if the proposal does not say which one, the client reads the most expansive version into it. Set it against a finish line both sides can be held to: “the project is complete when the eight agreed pages are live in production, populated with content you provide, and your team has had one training session on editing them.”

A proposal should connect to what the client is buying, not only to the inputs. Stark notes that the line items are “all INPUTS and DELIVERABLES,” but “what the client REALLY wants are BENEFITS.” The objective is where that benefit lives. You cannot promise a business result you do not control, and you should not, but you can state in a sentence or two at the top of the scope the outcome the client is paying to reach, so the deliverables read as the means to it rather than as a bill of materials.

The scope boundary is two lists, and the assumptions behind the second one hold the price

Every proposal has an in-scope list. It is the easy one, it is in every template, and writing it feels like the work. The list that holds the fixed fee is the one a thin proposal leaves out: what the project explicitly does not include. An out-of-scope list reads as competence, not as a wall. It is the part of the document that shows you thought about the project’s limits before asking for money, and the blank space where it should be does not stay blank. The client fills it in, in the most generous direction, after they have signed.

Here is the contrast. A weak scope line on a website project reads: “Full website redesign, 8 to 10 pages.” A strong one for the same project reads: “Redesign and build of eight pages (home, about, services, three service detail pages, contact, blog index). Page count is fixed at eight; additional pages are quoted separately. Out of scope: copywriting, photography, logo or brand work, ongoing maintenance, and migration of the existing blog archive. You provide final copy and images for all eight pages by the dates in the timeline; we provide layout, build, and one round of revisions per page.” The weak version priced a range and a verb. The strong version priced a countable thing, named where the project is not going, and said who owns the inputs. The client who reads it and still wants the blog archive migrated now asks for a quote instead of assuming it was always coming.

Behind the out-of-scope list sits the other half of the same job: the assumptions. The price and the timeline you wrote are both conditional. A fixed fee assumes the client provides content, access, approvals, source files, and a single decision-maker on time; that the existing system is what you were told; that the third parties involved do their part. Write those down as named assumptions and client dependencies, with dates where a date matters. The unwritten assumption is the line that becomes a fight three weeks in, and it fights from a strong position precisely because nobody put it on paper.

You scoped a website build at eighteen thousand dollars. Three weeks in, the client sends a few “small” content changes that turn out to be forty pages of copy you had assumed they would write. The proposal never said who wrote the copy, so the work is now yours, and so is the cost. There was no bad faith. There was a blank where an assumption should have been, and the blank defaulted to the client, because you are the one holding the fixed price.

Brennan Dunn frames the engagement as a two-way street, where the result is “only doable if you 1) provide the inputs on time and 2) work with us to ensure our outputs align with your expectations.” A dependency is just an input with an owner and a due date attached. “Client reviews designs promptly” is a wish; the version worth writing names the stakeholders, sets a response window in business days, and states that delays beyond it push the launch date by the same amount. Keep this commercial, not legal: you are naming what has to be true for the price to hold, not drafting terms. The assumptions are the baseline a change gets measured against, and you cannot call a request out of scope if you never wrote down what the scope assumed.

Phase the timeline by dependency, and write the change path before you need it

A timeline that is only a row of dates is a wish. Projects move when the thing the next step needs arrives, not when a date says it should. Phase the timeline by milestone, and at each one name what the client has to deliver for the next phase to start. That makes the dependency visible before it slips instead of after, and it turns “we’re behind” into a specific, locatable cause. Each phase should also end in something the client signs off, so the project does not reach the final week with every decision still open.

When the project is large or murky, the first phase can be the one that scopes the rest. David Baker and Blair Enns describe breaking bigger engagements into phases where “phase one is where you diagnose the problem”: you propose discovery as its own milestone with its own deliverable and sign-off, and the detailed scope of the build is one of the things that phase produces. Describe the milestones the way you would explain the project out loud. Discovery wraps when the sitemap is agreed and the content plan signed off. Design produces page templates, each approved before build starts. Build runs from those templates to a staging site for review; launch happens after final sign-off, once their content is loaded. The dependencies live inside those sentences.

The project budget can follow the same structure. In ProposalKit.io, the pricing table carries the fee as phase or milestone line items rather than one undifferentiated number, so the client sees discovery, design, and build priced separately. How you set those numbers is its own decision; our guide to proposal pricing and our post on pricing a creative project proposal cover the options.

The boundary moves. The proposal should say in advance how that gets handled: a request falling outside the agreed scope gets estimated and approved as a separate cost before any work on it starts. Done this way, the mid-project change is the client re-reading a clause they already accepted, not you raising the subject of money for the first time mid-delivery. Baker and Enns write: “you have to embrace change orders if you’re going to work this way.” Embracing them starts in the proposal, not in the email you send when you are already over budget.