Match the Pricing Model to the Uncertainty
Fixed pricing works when scope is known; hourly pricing works when it isn't — the mistake is applying the wrong model to the wrong situation
I've had this conversation more times than I can count: a client wants a fixed-price quote, I give them one, and then six weeks in we're renegotiating because the thing they wanted turned out to be three times more complex than either of us anticipated. Or the inverse: I bill hourly on something that was actually well-defined from day one, and the client spends the engagement anxious about the meter running.
Both outcomes are avoidable. The problem isn't the pricing model — it's using the wrong one for the level of uncertainty in the work.
Fixed price requires a stable scope
Fixed pricing works when you can write down what "done" looks like before anyone writes a line of code. That means the requirements are clear, the edge cases are understood, and the path from start to finish doesn't require much discovery.
When those conditions exist, fixed pricing is genuinely good for both sides. The client knows what they're paying. I know what I'm building. The contract eliminates a whole category of friction. There's no awkward conversation about unexpected hours; we either hit the scope or we don't.
The trap is quoting fixed when scope isn't actually stable. Early-stage product work is almost never stable. The client thinks they know what they want, and they do — until they see it working and realize the thing they described isn't quite the thing they needed. That's not a communication failure; it's how software discovery works. No amount of requirements documentation eliminates it at the early stage.
If I quote fixed on genuinely uncertain work, I'm absorbing risk the client should be sharing. I'll pad the estimate to compensate, which means the client overpays when things go smoothly and I still lose when they don't. It's not a good deal for either party.
Hourly pricing requires mutual comfort with open-endedness
Hourly billing on discovery-heavy work makes more sense in principle, but it carries its own failure mode: client anxiety. A client who isn't used to open-ended engagements will spend the project mentally watching the clock. Every decision becomes about whether it's worth the hours, which is exactly the wrong frame for the early exploratory phase.
The relationship has to support it. The client needs to trust that hours are being spent purposefully, and I need to be communicating what's happening so they're never left wondering what they're paying for. Weekly updates, clear descriptions of what got done and what's next — this isn't overhead, it's the mechanism that makes hourly work.
Hourly also works well for ongoing maintenance and support. The scope of "fix things that break and add small features" is inherently variable. Trying to put a fixed price on that either means leaving money on the table or overcharging for slow months.
The actual question is: what's unknown?
When I'm deciding how to price something, the real question isn't "does the client prefer fixed or hourly?" — it's "how much do we actually know?"
I go through it roughly like this:
Fixed price makes sense when: The integration points are defined. The data model is settled or can be settled before work starts. The feature is well-understood from prior similar work. There's a clear acceptance criteria that both sides can sign off on before we start.
Hourly makes sense when: We're early in a product and the requirements will evolve as the client sees the thing take shape. The work is inherently investigative — debugging a legacy system, auditing an existing codebase, exploring what's technically feasible. The scope is recurring and variable by nature.
Sometimes the answer is a hybrid: fixed price for the parts that are understood, hourly for the parts that aren't. That's not a cop-out; it's an accurate representation of what's actually known. A project might have a clearly defined backend API layer (fixed) and a UI that will need iteration based on real user feedback (hourly). Treating them the same way serves neither.
Don't let pricing preference override risk reality
Clients almost always prefer fixed pricing. It feels safer — you know what you're committing to. I understand the instinct. But a client who insists on fixed pricing for genuinely uncertain work isn't getting safety; they're getting a padded estimate, a contractor who's quietly cutting corners to protect margin, or both.
Part of my job is explaining this clearly before the engagement starts. If a client wants fixed pricing on something that doesn't support it, the honest answer is to break the work into phases: do a defined discovery phase for a fixed fee, then quote the build once we actually know what we're building.
That conversation is harder than just agreeing to whatever the client asks for. But it's the one that produces a project both parties feel good about when it's over.
Pricing is communication about risk
At bottom, the choice between fixed and hourly is a statement about who carries the uncertainty. Fixed transfers risk to the contractor. Hourly shares it. Neither is inherently fair or unfair — it depends on whether the model matches the actual shape of the work.
Getting this right requires being honest about what you know and what you don't, even when the client is pushing for certainty you can't actually provide. That honesty is more valuable to the relationship than any particular number on a proposal.