Three months late. $80k over budget. The agency is apologizing again. You have a board call next week and nothing to show that actually works.
You've heard the reasons. The requirements changed. There were technical complications they couldn't anticipate. The integrations took longer than expected. All of that may be true. None of it changes the situation you're in: a product that was supposed to be live, a budget that's been consumed, and a runway that doesn't extend.
What this actually costs
The $80k overrun is the easy part to calculate. The harder calculation is this: you had a market window. That window was sized around a specific timeline. For every month of delay, a competitor is shipping, a potential customer is evaluating alternatives, an investor is drawing conclusions about execution capability.
A six-month delay on a product with $200k monthly revenue potential costs $1.2M in lifetime value at a 3x multiple — before accounting for churn on the customers who found something else. The overrun is a line item. The delay is a company event.
The investor confidence cost is subtler and harder to recover. A board call where you explain a third missed milestone reads differently from a board call where you explain a deliberate scope change. Technical failures, when they're the result of poor planning rather than genuine technical unknowns, signal something about execution. Boards notice.
Why projects that get here stay here
Sunk cost paralysis is the most common trap. You've already paid $80k over budget to a team that hasn't delivered. The rational move is often to stop, audit, and decide with new information. The emotional move is to believe that one more sprint will get you there — because stopping and reassessing means acknowledging that the last three months were a loss.
Teams that stay in sunk cost paralysis spend another $80k and arrive at the same conversation five months later, except the market window is now closed and the runway is shorter.
Accountability gaps compound the problem. In most over-budget, behind-schedule situations, there is no one whose job it is to deliver the whole project. There's a project manager who tracks tickets, a technical lead who manages the sprint, and a client-side contact who monitors the budget. No one has the authority and visibility to see that the project is structurally broken rather than just behind.
Scope that was never properly defined is usually the root cause. "The requirements changed" is almost always true. What's also true is that requirements change on every project, and the projects that deliver on time have processes for managing that change. Projects that go over budget have scope that was agreed at a level of detail that felt comfortable but didn't account for the technical reality of building the thing.
The three failure modes
Bad estimation. This is the most common. The estimate was wrong because the estimator didn't have enough information to estimate correctly. They estimated at the level of features, not at the level of tasks. They didn't account for integration complexity, testing time, deployment setup, or the feedback cycles that every project has. The estimate was optimistic because the team wanted the project and the client wanted to hear a number they could afford.
An estimate built without understanding the technical constraints isn't an estimate. It's a guess with decimal points.
Moving scope. Scope moved — and no one tracked the cost of the moves. The client added features. The technical lead suggested a better approach to an existing feature. The integration requirement changed because the third-party API was different from the documentation. Each change was small. The cumulative delta is the overrun.
This is not the client's fault for having ideas. It's a process failure: changes were not being priced, documented, and approved before implementation. If every scope change had required a formal change order with a cost and timeline impact, the budget conversation would have happened every week in small doses rather than as a single catastrophic overrun.
Wrong architecture for the requirements. This one is the most expensive and the hardest to recover from. The technical team made architectural decisions early in the project that were reasonable given what they knew then, but which turned out to be wrong for the actual requirements. The wrong persistence layer. The wrong approach to real-time data. The wrong integration pattern. Each of these generates rework that compounds over the life of the project.
Bad architecture doesn't show up in week two. It shows up in month four, when the thing you're trying to build doesn't fit the foundation you built it on.
What an independent audit actually reveals
An audit of an over-budget project almost always finds the same things: the actual completion percentage is lower than the team's self-assessment, usually by 20–30 percentage points. The parts that are "done" have internal quality problems that will generate bugs in production. The parts that aren't done have dependencies on each other that make the sequencing harder than the project plan acknowledges.
The audit also usually finds a decision point: a specific architectural choice or scope definition that, if made differently, would have changed the outcome significantly. Finding that decision is the most valuable thing the audit does — not because it assigns blame, but because it determines whether the path forward is a course correction or a restart.
The uncomfortable finding: most over-budget projects are also structurally broken. The budget overrun is the symptom. The cause is either an architecture that doesn't fit the requirements or a scope process that didn't work. Neither of those problems is fixed by adding more time to the existing plan.
The decision: fire and restart, or course-correct in place
Course-correct wins when: the architecture is fundamentally sound, the overrun was driven by scope movement and poor estimation rather than technical decisions, the team understands what they built, and there's a clear, locked scope for completion.
Course-correction in place requires three things: a complete and honest audit of what exists, a fixed scope that will not change, and a different process for managing the remaining work. If any of those three things isn't present, course-correction becomes another iteration of the same failure mode.
Restart wins when: the architectural decisions are wrong for the requirements and fixing them requires rebuilding core components, the team that built it can't be trusted to complete it within a realistic budget, or the codebase has accreted so many workarounds that the incremental cost of working within it exceeds the cost of rebuilding.
A restart doesn't mean discarding everything. A well-scoped restart preserves the database design (if it's sound), the business logic that was correctly implemented, and the UX decisions that have been validated. It discards the implementation that doesn't fit the requirements and rebuilds it from the foundation up, with the knowledge accumulated in the failed first attempt.
How to restart without losing what you've built
The instinct in a restart is to throw everything out and begin fresh. That instinct wastes the most valuable asset of a failed project: the knowledge of what didn't work.
Before any new code is written, document: the features that are working, at the integration test level. The business logic that is correct, even if the implementation is wrong. The database schema decisions that are sound. The API contracts that have been agreed with external consumers.
The restart scope is built from that documentation. Everything on the "working and correct" list is preserved. Everything on the "technically broken or architecturally wrong" list gets rebuilt. The scope of the restart is exactly the delta, no larger.
What resolution looks like
A recovered project — whether course-corrected or restarted — has a specific set of properties that the original project never had: a locked scope document that was agreed before code was written, a test suite that validates the working behavior, a deployment pipeline that doesn't require a specific person's tribal knowledge to operate, and a completion date that was set from task-level estimates rather than feature-level guesses.
The product ships. Users use it. The board gets a demo that works.
This is for you if
You're a founder or CEO holding a project that is late, over-budget, and not working — with a board call, an investor demo, or a product launch that can't be delayed indefinitely. You need an honest assessment of what you have, a clear recommendation on path forward, and a team that can execute against it.
Engagements of this type run $50k–$200k depending on what's been built, what needs to be completed or rebuilt, and how urgent the timeline is. The audit that precedes any execution is scoped and priced separately.
This is for urgent situations with real timeline pressure. It's not for teams that want to take 6 months to find the perfect architectural answer. It's for founders who need to ship and need someone who has done this before to help them get there.