"Can you give me a fixed price for this?" is a reasonable question, and for some work the answer is a straightforward yes. For the work I mostly do — payment integrations, entitlement systems, infrastructure that has to not fall over — the honest answer is "not yet, and be suspicious of anyone who says otherwise."
That is not a dodge. It is what estimating this kind of work actually looks like.
Why clients want a fixed price
The reasons are legitimate. A fixed number is a budget you can take to a board. It is protection against a contractor who quietly bills forty hours for twenty hours of work. It moves the risk of things going long onto the person doing the work, which is often exactly where a client wants it.
Fixed price is a risk transfer, and sometimes it is worth paying a premium for. The question is whether the risk being transferred is one anyone can actually price.
Why it breaks on integration work
The part of an integration you can estimate is the happy path: the flow where the payment succeeds, the webhook arrives once, the token is valid, the network holds. That part is maybe a fifth of the real effort.
The other four fifths is everything the happy path ignores. Idempotency for events that get delivered twice. The provider's behaviour under load, which is not in the docs. Reconciliation for when a notification never arrives at all. Refunds, proration, tax, strong customer authentication, currency rounding. The failure mode that only appears in production because it needs real concurrency to trigger. None of that is knowable in detail until you are inside the system, and a fixed quote for it is a number produced by guessing and then padding the guess out of fear.
That leaves two outcomes. The number is too low, and I absorb the overrun or start cutting corners to fit it. Or the number is too high, and you have overpaid for my uncertainty. There is no version where the guess is just right, because it was a guess.
The corner-cutting incentive is the real problem
This is the part worth saying plainly. Fixed price plus fixed scope plus reality intruding creates pressure to declare the happy path "done" and reclassify the failure handling as out of scope. The idempotency work, the reconciliation job, the retry logic — the exact code that stops a customer being double-charged six weeks later — is what gets quietly dropped to make the timeline.
A fixed price can end up buying you the demo instead of the product, and you do not find out which one you bought until something breaks.
When a fixed bid is honest
There is plenty of work where a fixed price is the right contract, and I will quote one happily: a marketing site, a CRUD admin panel, a data migration I have scripted before, anything where I have built the same shape three times and the unknowns are genuinely small. When the scope is bounded and the risks are understood, a fixed price is efficient and fair, and haggling over hours would just waste everyone's time.
The distinction is not "fixed price bad." It is "fixed price for work whose hard part is still unknown is a bet dressed up as a quote."
What I do instead for the uncertain work
A short, paid discovery phase — a few days to a week — whose entire job is to turn the unknowns into knowns: read the provider's actual behaviour, map the failure cases, spike the risky part, and come out with a real estimate and a plan you own regardless of whether I do the build.
Then the build runs on capped time-and-materials or milestone billing, where each milestone is a demonstrable outcome rather than a date. You see working software at every step, you can stop between milestones if priorities change, and nobody is incentivised to hide the difficult parts to protect a number.
What to ask a contractor who quotes fixed price instantly
Ask what they assumed about the failure cases — the double-delivered webhook, the dropped notification, the partial payment, the provider timing out mid-request. If there is a specific answer, the quote might be real. If the answer is vague, the number is fiction and the scope argument is already scheduled; it just has not happened yet.
FAQ
Fixed price or hourly for software development?
Fixed price when the work is well-bounded and you've done that exact shape before — brochure sites, standard admin panels, scripted migrations. Time-and-materials or milestone billing when the hard part is genuinely unknown up front, which is most integration and infrastructure work. The mistake is forcing a fixed price onto work whose risks nobody can price yet.
Why are software estimates always wrong?
Because the estimable part of a task — the happy path — is a small fraction of the real effort, and the rest only becomes visible once you're inside the system. Early estimates are made at the point of maximum uncertainty, so they're guesses, and padding a guess doesn't make it accurate.
What is a discovery phase?
A short, separately paid piece of work whose only goal is to reduce uncertainty: read how the third-party system actually behaves, map the failure cases, prototype the risky part, and produce a real estimate and plan. You keep that output whether or not the same person does the build.
Isn't time-and-materials just a blank cheque?
Not if it's capped and billed against milestones that are demonstrable outcomes rather than dates. You see working software at each step and can stop between milestones. The protection comes from visible progress and the ability to walk away, not from a number fixed before anyone understood the problem.
How do I protect my budget without a fixed price?
Set a cap, break the work into milestones tied to outcomes you can see, and review at each one. Run a discovery phase first so the estimate is grounded. That gives you budget control and the option to stop, without forcing the contractor into a guess they'll have to cut corners to honour.
When should I ask for a fixed bid?
When the scope is genuinely bounded, the contractor has built the same thing several times, and the unknowns are small — a standard site, a known migration, a well-specified internal tool. In those cases a fixed price is efficient and fair.
Further reading
- Basecamp — Shape Up: Set boundaries — budgeting with an "appetite" instead of an estimate
- Steve McConnell — The Cone of Uncertainty — why estimates made early are necessarily wide
- Woody Zuill — The #NoEstimates movement — the argument for steering with small increments rather than forecasts
- martinfowler.com — Purpose of Estimation — when estimating earns its cost and when it doesn't
- Dan Luu — Concrete advice for estimating — practical notes on making estimates less bad when you have to make them
Related on this site: leaving the cloud is having a moment is the same instinct — price the whole thing, not the headline number; AI writes the code now is why the hard, unestimable part didn't get cheaper even as the typing did. See the kind of work this applies to in the Protect-A-Plate case study, or get in touch to talk through scoping a project.