How we scope a fixed-price project instead of quoting hourly

An hourly quote is really just an estimate wearing a different outfit. It shifts the risk of getting the estimate wrong onto whoever's paying the invoice, which is exactly backwards from how it should work. We quote fixed price on nearly every engagement, and the discipline that requires is worth walking through, because it's also the best way to judge whether an agency actually understands your project before they start it. A vague hourly range is easy to produce. A specific fixed number is not, and that difficulty is doing useful work.

The first draft of any proposal is a literal list: pages, components, integrations, content types, states. Not "website redesign," but "12 templated pages, one custom booking flow with three steps, a blog with category filtering, migration of 340 existing URLs with redirects." Every item on that list gets built into the price. Anything not on the list is explicitly out of scope, which sounds restrictive until you realize it's what makes the number trustworthy.

This also surfaces disagreements early, which is the point. If a client expected the booking flow to include payment processing and it's not on the list, that comes up in the proposal review, not in week six when someone assumed it was already covered. We'd rather have an uncomfortable five-minute conversation before a contract is signed than a much worse one three weeks into a build.

Once the list exists, pricing it draws on comparable past projects more than a bottom-up hours estimate. A 12-page marketing site with one custom flow has a price range based on dozens of prior builds, adjusted for anything genuinely unusual in this one. That range gets tighter the more specific the deliverable list is, which is the actual reason detailed scoping matters: vague scope produces vague, defensive pricing that pads for uncertainty on both sides.

This also means our estimating mistakes are ours to absorb, not yours. If a deliverable takes longer than we priced it for, that's a pricing error on our end, not a change order, and it doesn't show up as a surprise line item on your invoice.

Fixed price only works if scope changes are handled honestly instead of quietly absorbed or quietly ignored. When a client asks for something not on the original list, we price it as a discrete addition with its own number, rather than letting it blur into the existing budget. That keeps the original number meaningful and gives the client a clear choice about whether the addition is worth the cost, instead of discovering months later that the project quietly ballooned past what was agreed.

We log every one of these requests the moment they come up, even small ones, so nothing gets forgotten and nothing gets silently folded into the build without a client actually deciding it's worth doing.

A fixed price is only as good as the information it's based on, so we ask for real specifics before quoting: existing brand assets, examples of sites or products the client likes and dislikes, any integrations that have to work with existing systems, and a rough sense of timeline pressure. A client who can't yet answer these questions usually isn't ready for a fixed-price contract, they're still in a discovery phase, and we say so rather than quoting a number built on guesses.

Fixed price isn't free of tradeoffs. It requires more upfront scoping time before a contract gets signed, and it's a worse fit for genuinely exploratory work where nobody yet knows what's being built. For anything with a definable deliverable list, though, it's the version that puts the estimating risk where it belongs, on the team making the estimate, which is exactly how it should work for anyone paying for the outcome rather than the hours.

We've inherited a few projects from other agencies where the original scope document was a single paragraph of marketing language rather than a checklist. Words like "modern, responsive design" and "robust functionality" tell you nothing about what actually gets built, and they leave enormous room for both sides to disagree later about what was promised.

A document like that isn't really a scope, it's a mood board with a price attached, and it's the single most common root cause we see behind a client and an agency ending up in a dispute six weeks into a project.

We encourage clients to ask a competing agency for the same level of deliverable detail we provide, not just a total number. Two proposals with wildly different prices for the "same" project often turn out to be pricing different amounts of actual work, and the gap disappears once both are broken down the same way.

This is genuinely useful advice even for a client who ends up choosing someone else, because it protects them from the version of scope creep that starts with an unrealistically low number that was never going to cover the real deliverable list.

We don't produce free design concepts or working prototypes as part of a sales process, a practice sometimes called spec work. Real scoping and a real proposal take genuine effort on our side, and we're willing to invest that before a contract exists, but building actual deliverables without a signed agreement devalues the work for everyone in the industry, not just us.

The feedback we hear most often after a first engagement isn't about the design or the code, it's relief that the invoice matched the number they signed up for. That's a low bar in the abstract, and a surprisingly rare experience in practice, which says more about the industry norm than it does about anything unusual we're doing.

Occasionally a client will ask us to simply lower the price without changing the deliverable list, treating it as an opening offer to negotiate. We don't do this, because the number was built from the actual list, not padded to leave room for a discount. If budget is genuinely tight, we'll work with the client to reduce scope to fit it, trimming specific deliverables until the number matches what they can spend, which keeps the relationship between price and deliverables honest on both sides rather than eroding the number for reasons unrelated to what's actually being built.

It happens occasionally despite careful scoping, a deliverable turns out to be more involved than our estimate assumed, usually because of something neither side could have reasonably anticipated during scoping, an undocumented quirk in a legacy system we're integrating with, for instance. When that happens, we absorb it. We don't go back to the client mid-project asking for more money to cover our own estimating miss, because that would defeat the entire purpose of quoting fixed price in the first place, and it would shift risk back onto the client exactly where we said it wouldn't sit.