The Anatomy of a Software Rescue: What Happens When a Project Goes Wrong
Blog
All Articles
Engineering

The Anatomy of a Software Rescue: What Happens When a Project Goes Wrong

Mikael Löfberg November 11, 2026 5 min read
Nearly one in five software projects, 19 percent, is cancelled outright before it ever ships. That figure comes from the Standish Group's CHAOS research, which has tracked tens of thousands of projects for three decades, and it has barely moved since the 1990s. Stack on the projects that limp over the line late, over budget, and missing half their features, and the picture gets bleaker: a 2020 CHAOS analysis of roughly 50,000 projects found that 66 percent ended in partial or total failure. So if you are sitting on a build that stalled, that ran out of money, or that a previous developer simply walked away from, here is the first thing worth knowing. You are not an outlier. You are the statistical norm. And the second thing worth knowing is that failure is rarely the same as worthless. ## The numbers nobody puts in the pitch deck The money involved is genuinely staggering. The Consortium for Information and Software Quality estimated that software-development failures cost the United States 260 billion dollars in 2022 alone, with operational software failures adding a further 1.81 trillion on top. For context, that combined figure dwarfs the entire US defence budget for the same year. The other number that matters to anyone mid-build is turnover. Outsourcing firms run an average annual staff turnover of around 20 percent, and that churn is estimated to touch roughly 40 percent of active projects. Translation: the developer who started your project is statistically unlikely to be the developer who finishes it, even when nobody changes vendors. Mid-build developer changes are not an unlucky exception. They are baked into how the industry operates. ## What is usually salvageable, and what is not Here is the part that surprises people. When we open the hood on a failed project, the verdict is rarely all or nothing. The database schema and the business logic are usually the most valuable survivors. Someone spent months learning your domain, your edge cases, your pricing rules, and that knowledge is encoded in tables and functions whether or not the code around it is tidy. The hardest part of any build, understanding what the software is actually supposed to do, has often already been paid for. What does not survive as well: half-finished UI built on abandoned frameworks, authentication and payment flows wired up insecurely, and anything held together by a single person's undocumented assumptions. The honest rule of thumb is that the closer something sits to your data and your domain, the more likely it is worth keeping. The closer it sits to fashion and framework choices, the more likely it gets replaced. ## How an honest takeover actually works The instinct, when a project goes wrong, is to demand a rebuild from scratch. It feels clean. It is also usually the wrong call, because it throws away the domain knowledge that survived and resets the clock to zero. A real rescue starts with an audit, not a teardown. You read the code, run it, map what works against what is claimed to work, and check the security of anything touching money or personal data. Only then can anyone tell you, honestly, what percentage is keepable. Sometimes it is 70 percent and the project is back on track in weeks. Sometimes it is 20 percent and the kindest thing we can say is that the requirements were valuable even if the code was not. Either way, the answer comes from looking, not from a sales reflex. ## True Dev's take We have been building software since 1997, and a meaningful share of our work is picking up projects that other developers left behind. We have learned to resist the rebuild reflex, because clients who have already lost money to one failed build do not need to lose more proving a point. So our promise on a rescue is unglamorous: an honest audit first. We will tell you what is worth saving and what is not, even when "keep it" is the less profitable answer for us. A failed build is common, it is rarely fatal, and it almost always deserves a second opinion before anyone reaches for the delete key. If you are staring at a stalled project, [start a conversation with us](/start-project) and we will give you a straight read. You can also see the full range of [what we do](/services), from rescues to ground-up builds. Nearly one in five projects gets cancelled. Yours does not have to be one of them.
Share this article:

Stay Updated

Get our latest insights on AI, web development, and digital transformation delivered to your inbox.

No spam, unsubscribe anytime.

Mikael Löfberg

Mikael Löfberg

Founder, TrueDev

Mikael Löfberg is the founder of TrueDev with 29 years of experience developing digital solutions focused on business impact, user experience, and execution. He has built and run multiple companies across IT, media, real estate, and security — giving him a broad understanding of technology, strategy, and commercial requirements.

That perspective shapes everything TrueDev does. The goal is never just to build working systems, but to create solutions that strengthen the business, streamline operations, and deliver lasting value.

Connect on LinkedIn