Estimating Fixed-Fee Projects Without Losing Money

Fixed-fee projects are where you make — or lose — your margin. A practical method for estimating scope, pricing in buffers, and protecting yourself from creep.

Fixed-fee pricing is the most profitable way to work — when your estimate is right. When it's wrong, you've effectively agreed to work for free for however many hours you underbid. The difference between the two outcomes isn't luck or experience alone; it's a repeatable estimating method that accounts for the work you can see, the work you can't, and the work the client will inevitably add later. Here's how to quote a fixed fee you can actually deliver on profitably.

Never estimate the project — estimate the tasks

A single number for the whole project is a guess wearing a suit. The reliable way to estimate is to break the work into the smallest tasks you can name, estimate each one, and add them up. The act of decomposition surfaces the steps your gut quietly skips — the QA pass, the second round of revisions, the deployment, the handoff call.

List every deliverable, then break each into concrete tasks.
Estimate hours per task using your honest past performance, not your optimistic self.
Total the hours, multiply by your target rate to get a baseline price.
Sanity-check the total against any similar project you've actually done.

Price in the work you always forget

Every estimate omits the same invisible work: communication, context-switching, the revision you didn't expect, the dependency that wasn't ready. This isn't padding — it's the real cost of delivering. A buffer of 20–30% on top of your task total covers it for most work; complex or first-of-its-kind projects deserve more.

The buffer isn't profit and it isn't padding. It's the budget line for everything you know will happen but can't itemise yet.

The only way to size the buffer well over time is to compare your estimates against reality. Track actual hours against the project — even on a fixed-fee job where the client never sees the timer — so you learn exactly how far off your guesses run. Kliently's time tracking lets you log billable and non-billable time per project, so after a few jobs your buffers stop being guesses.

Write scope as inclusions and exclusions

Scope creep doesn't usually arrive as a big new request — it arrives as a series of small, reasonable-sounding additions that the client genuinely doesn't see as out of scope. The defence is to write the scope in two columns: what's included, and a short, explicit list of what's not. The exclusions do most of the work, because they convert a future argument into a pre-agreed boundary.

Included: the exact deliverables, the number of revision rounds, the file formats, the timeline.
Not included: extra rounds, new pages or features, content the client must supply, ongoing support.
Change requests: a line stating that anything outside the scope is a separately quoted add-on.

Put this directly in the proposal so the client accepts the boundary at the same moment they accept the price. When acceptance can auto-create the matching contract, your scope is captured as a signed agreement, not a hopeful email. See proposals and contracts for how that handoff works.

Bill on milestones, not on completion

A fixed fee paid entirely at the end means you finance the whole project out of your own pocket and carry all the collection risk. Split the fee into milestones tied to real checkpoints — a deposit to start, a payment at a meaningful midpoint, the balance on delivery. Cash arrives while you're still working, and a client who's paying along the way is a client who's committed.

Deposit on signature (more on getting deposits right in our resources guides).
Progress payment at a defined milestone the client can see and approve.
Final balance on delivery, invoiced the moment the last deliverable ships.