How we scope a fixed-bid project honestly

A fixed-bid project is a promise about the future made with incomplete information. That’s not a reason to avoid them — clients often genuinely need a fixed number to make a decision — but it is a reason to scope them honestly, because the alternative is a quote that’s really just optimism with a decimal point.

A fixed bid with an “and any other features as needed” clause isn’t a fixed bid. It’s a disagreement that hasn’t happened yet.

Separate what’s known from what’s a guess

When we read a brief, we sort every line into one of two buckets: things we can size confidently, and things we’re guessing at. “A login screen” is known. “Integrate with their existing inventory system” is a guess until we’ve seen that system. We make this split visible to the client, because the guesses are where a fixed bid goes wrong, and pretending they’re knowns is how you end up eating the difference.

Price the guesses by reducing them first

For anything in the guess bucket, the honest move is to shrink the unknown before quoting it. Sometimes that means a short paid discovery phase. Sometimes it’s an hour on a call with their existing developer. The cost of that hour is nothing next to the cost of quoting a two-week integration that turns out to be six.

Quote the project you’ll actually build, not the ideal one

Every brief contains features that sound essential and turn out to be decoration. Part of scoping honestly is pushing back before the quote: do you need user-configurable dashboards in v1, or do you need to launch? We’d rather quote a smaller, real project that ships than a larger, impressive one that stalls at eighty percent. So we write down what’s in, and just as importantly what’s out, so that “out” is a conversation and not a surprise.

Build a real buffer, and call it what it is

We add contingency to every fixed bid, and we don’t hide it in inflated line items. Things go wrong that aren’t anyone’s fault — an API changes, a library has a bug, a requirement was understood two different ways. The buffer is what lets us absorb that without either eating the cost or going back to the client with our hand out.

When scope changes, stop and re-decide together

The thing that actually kills fixed-bid projects isn’t the original estimate being wrong. It’s scope creeping silently until the original number stops meaning anything. So when a change request lands that’s outside what we scoped, we don’t quietly do it and resent it, and we don’t refuse it on principle. We stop, show the client the trade-off — this is new, here’s what it costs in money or time — and let them decide with real information.

Done this way, a fixed bid stays honest the whole way through. The client gets a number they can plan around, and we get a project we can deliver without quietly losing on it. Both have to be true, or it isn’t really a deal.