What Do I Actually Put in a Fixed-Fee Proposal?

What do I actually put in a fixed-fee proposal?

Six things: the problem in the client's own words, exactly what I will deliver, exactly what I will not, the price, the timeline, and what I need from them. No case studies, no methodology diagrams, no company story. Six sections, usually under two pages.

I price everything fixed fee, and most of my projects land between one thousand and ten thousand dollars. That structure forces the proposal to do real work, because a fixed price cannot survive a vague scope.

What follows is what my proposals contain today, after six years and more than seventy projects, and the specific things I removed along the way because they never once helped.

Why fixed fee rather than hourly?

Because hourly billing makes efficiency a punishment. If I get faster at something, hourly means I earn less for the same result. Fixed fee aligns us: the client buys an outcome at a known price, and any speed I gain from experience belongs to me rather than being deducted.

It also changes the conversation with the client. Hourly invites questions about how long something took, which is not a question either of us should care about. Fixed fee invites questions about what they are getting, which is the right question.

The trade-off is real and I will not pretend otherwise. Fixed fee puts estimation risk on me. If I scope badly, I absorb it. That risk is exactly why the proposal has to be precise, and it is why I spend more time on scope than on anything else in the document.

What goes on the first page?

Their problem, written in their language, before anything about me. I use the phrases they used in the call. If they said the blog is invisible in AI answers, that is the sentence, not a rewritten version with my preferred terminology layered on top.

This section exists to prove I listened, and it does more work than any credentials page ever has. A client reading their own words back correctly is already halfway to trusting the rest of the document. A client reading a generic problem statement is bracing for a generic project.

It also protects both of us. If I have misunderstood the problem, this is where it surfaces, on page one, before anyone has committed to a number. I have had proposals come back with a correction to this section and no argument about anything else, which is exactly the right outcome.

What does not go on page one is my background. I am a Certified Webflow Partner working from Bengaluru, and that belongs at the end or nowhere, because by the time someone is reading a proposal they have already decided I am plausible.

How do I write scope so it actually holds?

As a list of specific artefacts with numbers attached, in prose rather than aspiration. Not "SEO improvements" but the exact pages I will rewrite, the exact schema types I will implement, and the exact number of articles. If it cannot be counted or pointed at, it does not belong in scope.

The test I apply to every scope sentence is whether two reasonable people could disagree about whether it was delivered. "Improve site performance" fails that test badly. "Implement the fixes identified in the attached audit for the six templates listed" passes it, because you can look and see.

I also name the deliverable format. A document, a Webflow build, a set of automations, a recorded handover. Clients have been burned before by work that was technically done and practically unusable, and naming the artefact removes that worry cheaply.

Where genuine uncertainty exists, I say so and price a discovery phase separately rather than padding a guess. That is honest, it is cheaper for them, and it has never once cost me a project. If you want the questions I ask before scoping this kind of work, I wrote them up in the discovery questions I ask before an AEO project.

Why write down what is not included?

Because every dispute I have ever had came from an assumption nobody stated. The exclusions section is short, unglamorous, and the highest-value paragraph in the document. It costs two minutes to write and it prevents the conversation that costs a relationship.

My standard exclusions are content writing unless it is named, ongoing maintenance after handover, third-party subscription costs, and anything requiring access I have not been given. None of these are surprising. They are only contentious when they are discovered in week five instead of read in week zero.

I write them plainly rather than defensively. Not legalese, just a short paragraph saying what this project does not cover and offering to include any of it if they want it priced. Framing the exclusions as available options rather than refusals turns a defensive section into a sales one.

When scope does drift anyway, and it sometimes does, having written exclusions makes the conversation administrative rather than emotional. I went into how I handle that in when a fixed-fee project goes over scope.

How do I present the price?

One number, stated plainly, with the payment schedule immediately under it. No ranges, no three-tier good better best table, no anchoring theatre. A single figure signals that I have thought it through, which is the impression I want more than I want an upsell.

I used to offer tiers because everyone said you should. What I found is that tiers move the conversation from whether to do the project to which version to buy, and that sounds clever until you realise the client now has to make a decision they are not equipped to make. They asked me for a recommendation. Three options is the absence of one.

The payment schedule goes directly underneath, because it is the second question every client has and making them ask it is a small unnecessary friction. Fifty percent to start and fifty on delivery is typical for me, with larger projects split into more milestones.

If the number is likely to be higher than they expected, I say why in one sentence next to it. Not a justification paragraph, one sentence. Explaining at length sounds like apologising, and a price you apologise for is a price you will end up discounting.

What do I ask from the client?

Specific things with names attached. Who approves, who provides content, what access I need and by when, and how quickly I need feedback for the timeline to hold. Every delay I have ever suffered came from one of those four being undefined at the start.

The approver question is the important one. If the proposal does not name a single person who can say yes to a design decision, the project will be reviewed by committee and the timeline will double. I would rather learn that during the proposal than in week three.

The feedback clause is the one people find unusual and then appreciate. I state the turnaround I need, and I state plainly that the timeline shifts if it slips. Not as a threat, as arithmetic. Clients are reasonable about this when it is agreed in advance and unreasonable about it when it is raised for the first time after a delay.

What have I stopped including?

Case studies, a methodology section, a company story, logos of past clients, and a detailed timeline broken into weeks. Every one of those made the document longer and none of them ever came up in a conversation that led to a yes.

Case studies went first. By proposal stage, a client has already seen my work. Repeating it inside the document that is supposed to answer questions about their project is a waste of their attention. If I mention past work now, it is one sentence, relevant to their exact problem, such as the automation work I did for Ajust or the HubSpot setup for Kismet Health.

The methodology section went next. A five-phase diagram makes the work look serious and tells the client nothing they can act on. What they want to know is what they get and when, which is the scope and timeline sections doing their job.

The week-by-week timeline went last and was hardest to give up. It looked professional. It was also fiction, because real projects move, and a document promising deliverables on specific Tuesdays creates a record of broken promises for no benefit. I give a total duration and the milestone points, and that is enough. My views on how long these documents should be are in the one-page brief versus the detailed proposal.

What should you do next?

Take your last proposal and delete everything that is about you rather than about them. Then check every scope line against the disagreement test: could two reasonable people argue about whether this was delivered. Rewrite the ones that fail. That is most of the work.

Then add an exclusions paragraph if you do not have one. It will feel awkward the first time and it will save you a difficult conversation within the year. The clients who react badly to clear exclusions are telling you something useful about how the project would have gone.

If you are pricing a project and not sure how to scope it so a fixed fee is safe, reach out. Getting the scope right is the part that actually decides whether a fixed-fee project is pleasant or painful for both sides. Let's chat.