A fixed-price engagement does not make the "how long will this take" conversation go away. It changes the shape of it. The first few fixed-scope projects I ran, I was still quoting hour estimates in the background, which meant I was still running hourly engagements wearing different clothes. The framework that actually works has three axes, and hours is not one of them.
The fork
After ending hourly billing, the first real problem is that clients still ask how long things take. They are not being difficult. Hour counts are the only vocabulary most buyers have for scoping technical work. The question "how long" is how they verify the price feels reasonable, and how they compare you to the next operator they are considering.
There are three honest ways to answer that question, and the first two are habits from the hourly model wearing different clothes.
Option A: Quote hours anyway, even on fixed price
The mechanic: set a fixed price on the engagement, but quote "about 40 hours of work" internally and sometimes externally to justify the number. The spreadsheet looks clean. The client gets a framework for understanding the cost. You get the certainty of a fixed price without losing the familiar anchor.
What it gives you: comfort. Clients respond to hour counts. They do the math, feel the number is reasonable, and move on. Internally, you know what "normal" looks like for this kind of project because you can compare it against historical hour counts.
What it costs: the same pathologies hourly billing produced. Scope-creep conversations still happen around hours ("this is taking longer than you estimated"). Rate negotiation still happens ("$4,000 for 40 hours is $100/hour, can we do $80"). The client's mental model is still hourly. You have changed the checkout page without changing the engagement.
I ran this for the first two fixed-price projects after transitioning. Both hit the same failure mode: mid-project, the client asked how many hours I was into the work. My honest answer was "I don't know, I stopped counting." The conversation got awkward. It turned out the hour estimate was load-bearing in the client's brain even though I had priced flat.
Option B: Quote days with buffer
The mechanic: shift from hours to days. "Two weeks of focused work, three weeks of calendar time." Cleaner conversation, fewer hour-level negotiations, and the buffer gives you air for unknowns.
What it gives you: a meaningful step up from hour-quoting. Days feel less industrial than hours. The client does not reach for rate-per-hour math. The buffer between focused work and calendar time gives you permission to take breaks, work on other projects, and come back without guilt.
What it costs: the frame is still time-input. The client still evaluates the engagement based on how many days of your attention they are buying, not based on what they end up with. The buffer gets consumed by "can you add just one more thing" requests, because the client sees time remaining and assumes the surplus is theirs. By week three of a three-week calendar window, the buffer is gone and the scope is 40% larger than agreed.
I ran this for a stretch of engagements and it was better than hours. It was not good enough. The thing that breaks both Option A and Option B is that the client's evaluation anchors on your time, and your time is not what they are actually buying.
Option C: Scope by deliverable, boundary, and decision point
The mechanic has three axes and every engagement names all three on paper.
Deliverable. The thing the client ends up with. Not "an audit," not "tracking work," but a concrete noun. "A 24-check scored report covering the commerce stack, delivered as a PDF." "Meta CAPI events firing in production with event_id deduplication, verified against the GA4 purchase event." "A Shopify theme in their repo, passing Core Web Vitals thresholds on mobile." The deliverable is what the client can point at when they describe what they bought.
Boundary. What is not included. Stated at the same prominence as the deliverable, not buried. "Not included: implementation of recommendations. Not included: ongoing support past delivery. Not included: changes to systems outside the commerce domain." Clients do not push back on deliverables. They push back on what is out.
Decision point. The evidence that proves the work is done. Not a calendar date. A condition the deliverable has to satisfy. "Purchase event fires with event_id on 100% of test transactions for 48 consecutive hours." "Scored report delivered and reviewed with the client in a 30-minute handoff." "Theme deployed to a preview URL and passes Core Web Vitals on mobile for three consecutive measurements." The decision point moves the end of the engagement from "when is it Friday" to "what does done look like."
What it gives you: a contract the client can read in 90 seconds. Both sides know what the engagement is, what it is not, and when it ends. Faster delivery is rewarded, not penalized. Scope-creep conversations stop being negotiations and start being explicit out-of-scope referrals.
What it costs: more thought upfront. The boundary is the hardest axis to get right the first time. Discipline during the engagement to hold the boundary when the client wants to expand scope, and to know what the referral path is for out-of-scope items.
Why I chose scoping without hours on three axes
Option C. The first fixed-scope engagement where I scoped it this way was a DTC analytics setup. The deliverable was named, the boundary was named, and the decision point was "Meta CAPI events fire with event_id dedup stably for 48 hours, confirmed by a screenshot of the Events Manager dedup tab."
The client signed the SOW without asking about hours. The engagement ran six weeks. I did not open a time tracker once. The decision point hit on a Wednesday in week five. I delivered the handoff, sent the final invoice, and closed the engagement. The client was happy because the deliverable did what it said. I was happy because the decision point had removed the "how long does this take" ambiguity that used to run every engagement.
“The decision point moves when-is-this-done from a calendar conversation to an evidence conversation.
”
The three-axis frame also mapped cleanly onto the productized tiers that came later. Every tier in the productized ladder overview at /products has a named deliverable, a named boundary, and a named decision point. The frame scales down from a custom engagement to a $129 product without changing shape. That portability is what makes it worth the upfront thought. The SOW shape that carries these three axes onto paper is documented in the two-page SOW template I ship with audit tiers.
What I would revisit
Three places I still get the frame wrong often enough to name.
The boundary deserves its own section in the SOW. I used to bury it in the scope paragraph, thinking visually-lighter boundaries would read as less combative. Clients read past them. Now the boundary gets its own heading, its own indent, and sometimes its own callout color. Making the boundary visually prominent is not aggressive. It is the most protective thing you can do for both sides.
The decision point needs to be something the client can verify, not just me. If the decision point is "Meta CAPI events pass dedup," the client has to be able to check that themselves. If the decision point is something only I can evaluate, the engagement ends on my word, which re-creates the "when is this done" ambiguity. Every decision point now gets a verification mechanism the client can run without me.
There needs to be a channel for out-of-scope items. Clients will ask for things outside the scope during the engagement. Always. The SOW needs to name a channel for that conversation so it does not become awkward. "Out-of-scope requests go on the post-delivery list; pricing for additions is quoted after the current engagement delivers." That one sentence prevents 80% of the scope-creep drift I used to fight.
Frequently asked questions
How do I estimate effort internally if I am not counting hours?
Estimate in days or half-days, internally, against prior projects of similar shape. "This looks like a two-week project with similar risks to the one I did last quarter." Do not surface the estimate to the client. It is a sanity check for your pricing, not a contract. If you are repeatedly off by more than 30%, your pricing (not your estimation) needs work.
What if the decision point turns out to be harder than I thought?
First, check whether the decision point is genuinely harder or whether the scope crept into the engagement. If it is scope creep, hold the boundary and refer the extra work to a post-delivery add-on. If the decision point itself turned out to be harder than you estimated, absorb it. That is the risk you took on when you priced flat. The lesson is for the next SOW, not for the current client.
How do I handle clients who insist on an hour estimate?
Rarely a closer question than it feels. Clients who demand hour estimates are often evaluating you on the wrong axis, which means they are likely also the wrong-fit clients for the engagement. Answer once: "I scope by deliverable rather than hours; I can give you a rough day-count for your planning, but the engagement is priced against the deliverable, not against hours worked." If they push harder, they are a bad fit. Refer them to an hourly operator or close the conversation.
Can I use this framework on a retainer?
The frame adapts but not cleanly. Retainer work is usually ongoing-attention-based, which breaks the "decision point" axis. On the retainer-bridge slots running through the sunset window, the scope is time-plus-deliverables: reserved attention for a capped number of hours per month, plus two named deliverables over the quarter. The decision point becomes per-deliverable rather than per-engagement. The framework carries over, it just runs cycle by cycle rather than once.
What does the scope section of a SOW look like?
Three headings, in this order: "What you get" (deliverable, concrete noun, verifiable artifact). "What is not included" (boundary, explicit list, not prose). "When the engagement is done" (decision point, a condition the client can verify). Each section is 2-5 sentences. The whole scope section fits on one page. If it runs longer, the engagement is too big and should be split into smaller named engagements.
Sources and specifics
- The "deliverable, boundary, decision point" frame is the scoping structure I have used across retainer-bridge engagements and every productized product on /products since 2025.
- The first fixed-scope engagement to use a verifiable decision point was a DTC analytics setup where the condition was "Meta CAPI events fire with event_id dedup stably for 48 hours."
- The hourly-ceiling math that triggered the shift is in the retrospective on why hourly billing stopped working.
- The comparison between retainer and productized cost structures is in the retainer-vs-productized breakdown.
- The three-axis frame maps directly onto the tiers covered in the full productized ladder guide, giving every tier a named deliverable, boundary, and decision point.