We get a specific kind of phone call.
It starts the same way every time. The business owner is frustrated but not angry. More exhausted than anything. They spent months, sometimes years, on a custom software project. They paid real money. Sometimes six figures. And the thing they paid for either does not work, sort of works but nobody trusts it, or was abandoned halfway through by a vendor who stopped returning calls.
The opening line is usually some version of: "I do not know if you can help, but..."
We can help. We do it regularly. And if you are in this position right now, here is what the recovery actually looks like.
The call
A professional services firm spent north of $200,000 on a custom platform. The vendor was offshore. The communication was fine at first. Weekly calls. Demo videos. A staging environment that looked promising.
Then the delays started. The staging environment stopped getting updated. The calls became biweekly, then monthly, then stopped. The vendor went dark. The codebase was delivered, but it did not work. Key features were missing. The ones that existed were buggy. Nobody on the client's team knew how to run it, let alone fix it.
They called us because they had two choices: walk away from $200,000 and start over, or find someone who could salvage what was there.
Step one: the codebase assessment
The first thing we do in a rescue situation is not write code. It is figure out what we are looking at.
A codebase assessment answers three questions. First, does the code actually work? Not "does it run without errors." Does it do the things the business needs it to do? Second, is the architecture sound? Can this codebase be built on, or is it fundamentally broken in a way that makes continued development more expensive than starting over? Third, what is missing? What features were promised but never built? What was built but never tested?
The assessment on this particular project took about a week. The answer was better than feared and worse than hoped. The core architecture was workable. The database schema was reasonable. But the business logic layer was incomplete, the UI was riddled with inconsistencies, and there was no documentation, no test suite, and no deployment process.
It was salvageable. But it was going to take real work.
Step two: stabilize before you build
When you inherit a broken codebase, the instinct is to start adding features. That is a mistake. You cannot build on a foundation that is cracking.
The first phase of recovery is stabilization. Get the application running reliably in a controlled environment. Fix the critical bugs that prevent normal use. Stand up a deployment pipeline so changes can be made without fear of breaking production. Write enough tests to catch regressions in the most important workflows.
This phase is boring. It does not produce visible new features. The client sees very little change week to week. But skipping it is why many rescue attempts fail. If you start building new features on top of a shaky foundation, you just create a larger pile of broken code.
For this client, stabilization took about three weeks. By the end, the application ran. Deployments were automated. The team could make changes without holding their breath.
Step three: build toward the original vision, one piece at a time
Once the foundation is stable, you can start building again. But you do not try to build everything at once. You pick the highest-value feature that was missing or broken, build it, test it, ship it, and get feedback. Then the next one. Then the next.
This is how healthy software development works in general. It is especially important in a rescue because the client has already been burned. They need to see working software shipping on a regular cadence before they can trust the process again.
For this client, the first feature we rebuilt was the client portal. It was the thing their customers interacted with most. Getting it right restored confidence internally and externally. After that came reporting, then billing integration, then the remaining workflow automation.
The full recovery took months, not weeks. But after the first month, the application was in production and being used. After three months, the original scope was complete and the team was adding new features that were not part of the original plan. The project went from a disaster to a working system.
Why projects fail in the first place
If you are considering a custom software build, or if you are in the middle of one that feels like it might be going sideways, here are the patterns we see most often.
No discovery phase. Someone wrote code before anyone understood what the business actually needed. This is the single biggest predictor of failure. Discovery is not expensive. Skipping it is.
No single accountable person. The vendor assigned a team but nobody on that team was responsible for the outcome. When things went wrong, everyone pointed at someone else. You need one person who owns the result.
Hourly billing with no deliverables. The vendor got paid regardless of whether anything shipped. Incentives matter. If the vendor makes more money when the project takes longer, the project will take longer.
No code ownership until the end. The vendor held the code hostage pending final payment. When the relationship broke down, the client had nothing. You should own your code from day one.
Misaligned incentives. The vendor was incentivized to build more features. The client needed the features to actually work. Quantity over quality is a predictable failure pattern.
If you are in this situation right now
First, do not panic. More projects fail than anyone in this industry admits. You are not uniquely bad at hiring developers. You probably made a perfectly reasonable decision with the information you had at the time.
Second, get a codebase assessment. Before you decide whether to salvage or restart, you need someone who knows what they are looking at to tell you what you actually have. A good assessment takes days, not weeks, and costs far less than either rebuilding from scratch or sinking more money into a broken codebase.
Third, be skeptical of anyone who promises to fix everything in two weeks. Real recoveries take time. Anyone who tells you otherwise is about to become the second vendor you fire.
Finally, the best time to set up a healthy development relationship is before things go wrong. The second best time is right now.
Book a discovery session if you are sitting on a software project that is not working and need someone to tell you honestly what it will take to fix it.