When a project runs over budget, who pays for it

Cost overruns happen for genuinely different reasons, and treating them all the same, either always absorbing the cost or always passing it to the client, is unfair in one direction or the other depending on the actual cause. We categorize overruns by cause before deciding who's responsible.

If a task took longer than we quoted because we underestimated its complexity, that's a mistake in our own process, and we absorb it. This is exactly the risk fixed-scope pricing is designed to place on us rather than the client, and we hold to that even when it stings on a specific project.

If a client adds a feature or requirement that wasn't in the original scope, that's new work, not an overrun, and it gets priced and approved as an addendum before we start it. This isn't really a cost overrun in the sense the phrase usually implies, it's a scope change with its own price tag.

If a client's own internal approval process, a slow third-party API partner, or a delayed content delivery pushes a timeline out, that's genuinely nobody's estimating error, and we handle it case by case, usually with a timeline extension rather than a cost change, since our actual hours worked haven't necessarily increased.

Sometimes a requirement that seemed clear at scoping turns out to be more complex once we're actually building it, not because either side made an obvious mistake, but because some things are genuinely hard to fully scope until you're inside the work. We treat this as shared risk and have an honest conversation about it rather than defaulting to either extreme.

For the rare case where it's genuinely unclear whether something was an estimating error or a legitimate gray-area complexity, we default to treating it as our own risk rather than the client's, and address it internally afterward by improving how we scope that specific type of work in future proposals, so the same ambiguity doesn't recur.

Most cost-overrun disputes we've seen at other agencies come from this categorization never being made explicit, so both sides default to assuming the other is at fault when a number changes. Naming the categories in the initial contract, before any project starts, removes most of the ambiguity that turns a normal project bump into a relationship-damaging argument.

We flag a cost or timeline impact the moment we identify it internally, not at the next scheduled status meeting or, worse, at final invoicing, since a client who learns about an overrun early has real options, adjust scope, extend timeline, accept the cost, while a client who learns about it after the fact has none. Early, unprompted disclosure of a problem is one of the clearest signals of a trustworthy vendor relationship, and we treat it as non-negotiable regardless of how uncomfortable a specific conversation might be.

We've found that clients respond far better to an early, honest "this is turning out more complex than we scoped, here's why and here's what we recommend" than they ever would to the same information delivered defensively after the fact. The discomfort of raising it early is real but genuinely smaller than the damage caused by a client discovering the same issue on their own weeks later.

On one project, a client's existing payment processor turned out to have undocumented rate limits that weren't discoverable until we were actually integrating against it, well past initial scoping. We flagged it within a day of discovering the issue, classified it as our own estimating gap since a more thorough technical discovery would have caught it, and absorbed the additional week of work rather than passing the cost to the client.

Absorbing our own estimating errors on every project does have a real, measurable cost to our margin over a given year, and we've made peace with that cost as the price of a pricing model clients can actually trust. A policy that only holds up when it's convenient isn't really a policy, and the trust it builds pays for itself many times over in renewals and referrals.

We log every overrun, its category, and its root cause in an internal record reviewed quarterly, specifically looking for patterns across projects rather than treating each one as an isolated incident. A specific type of integration that's caused an estimating miss on three separate projects is a signal worth acting on, not three unrelated coincidences, and this record is how we actually catch that kind of pattern.

This tracking has directly changed how we scope certain categories of work, adding explicit discovery time for third-party integrations we've been burned by before, building in a wider estimating buffer for a type of feature that's consistently proven harder than it initially looks. The goal isn't to eliminate overruns entirely, since some irreducible uncertainty is inherent to real project work, but to make sure the same avoidable mistake doesn't happen twice.

Clients who provide clear, complete answers during discovery and who designate a single decision-maker with real authority to approve scope questions quickly tend to see meaningfully fewer overruns than clients with slower, more diffuse internal approval processes, since a lot of what looks like an overrun is actually a delay compounding into a cost. We flag this directly in kickoff conversations, since it's one of the few overrun risk factors genuinely within the client's own control, and clients who take that flag seriously tend to be the same ones we look back on later as our smoothest, least contentious engagements.