Software project rescue starts with a diagnosis you can finish in one to two weeks, not a contract. Find out whether the project still builds, tests and deploys. Stabilise it before anyone adds features. Decide between rescue, restart and rewrite on evidence you can check yourself, and keep whoever does the work on short, gated terms. This page is the decision stage, and it sits inside the wider choice of delivery models in Software development engagement models: staff augmentation, dedicated teams, nearshore and offshore. If you've already decided to change teams, the mechanics of ownership, access and handover are in the guide to moving outsourced work in-house.
What counts as a software project rescue?
A rescue is the triage and recovery of a project that's late, over budget or stalled: a product an agency or offshore team built, a build that stopped shipping, or a half-finished product nobody fully understands. The goal is a releasable product, not a pretty codebase.
It isn't a staffing swap. One engineer who's underperforming is a matching problem. A rescue is for the case where the project as a whole has stopped converging on a release, whoever is on it.
It also doesn't require firing anyone. A rescue can run alongside the current team, with the incumbent kept on a narrower brief, or it can move to new hands. Which one is a later decision. The first job is finding out what you actually have.
Is your project recoverable?
Most of what you need is observable this week, without reading code. Ask the team to show you each item on a screen share rather than describe it. The thresholds below are our judgment, not an industry standard.
| Check | Recoverable if | Restart or rewrite if |
|---|---|---|
| Clean build | A new engineer can build and run it from a fresh checkout in a day or two | Nobody can build it without one specific person or machine |
| Deployment | The team deploys to a real environment, even clumsily | Production is a hand-edited server nobody can recreate |
| Tests | Some tests exist, run and fail for real reasons | None exist, or they're all disabled or meaningless |
| Domain logic | The business rules work, even if the code around them is ugly | The core rules are wrong or scattered so widely nobody can state them |
| Platform | Framework and runtime are still supported | They're end-of-life and the upgrade path is a rewrite anyway |
| Scope | The original scope still describes what you need | The market or product changed and the scope is stale |
A project can fail the first row and still be worth saving, because a build nobody can reproduce can be a small fix (in our experience days rather than weeks, though it depends on the system). It's the combination of wrong domain logic, no tests and a stale scope that points to a restart.
Rescue, restart or rewrite: how to decide
The three words get used loosely, so pin them down. Rescue keeps the codebase and fixes what blocks a release. A rewrite replaces the code but keeps the product definition and the data. A restart throws away the code and the plan, and re-scopes from the problem.
Four questions decide most cases:
- Does it still build and deploy from a clean checkout?
- Do the tests mean anything?
- Is the domain logic right, even where the code is ugly?
- Is the original scope still the right scope?
Four yeses mean rescue. A no on the first two is often cheaper to fix than the alternatives, so don't rewrite over it. A no on the third is where rewrites become the honest answer, because you'd be maintaining wrong behaviour. A no on the fourth means more code won't help, and you're looking at a restart on a smaller scope.
Remember that a rewrite has its own failure mode: it's a new project with the same team habits that produced the first one. DOOR3, a rescue vendor, says the rescue-or-start-over call rests on a risk assessment of strategic fit, financial impact, available resources and market dynamics, with contractual and legal obligations reviewed first, and with input from the team that will take over. We'd add one more input: who can credibly maintain the result.
How to rescue a failing software project
1. Freeze scope and cap the weekly spend
Pause new features and stop paying for open-ended hours while you assess. Nothing gets better by adding scope to a project that can't ship what it already has.
Before you negotiate anything, confirm you hold admin rights on the code repository and the cloud account. If you don't, the offshore team replacement guide covers how to get them. That's the only access step this page covers.
By the end of this step you have a written pause on feature work and a list of what's currently costing money each week.
2. Run a timeboxed independent assessment
Give one or two senior engineers one to two weeks to answer a single question: what would it take to ship? "Independent" means they don't gain from the answer. That rules out the vendor that built the product, and it's better if it rules out whoever hopes to win the rescue work too.
Ask for a written report you own, covering build, test and deploy status, the top risks, basic security hygiene, and what's salvageable. This is a triage report, not an inventory of every asset. If the person writing it can't say "restart" when that's the answer, the report isn't independent.
3. Restate the goal and cut to a first releasable slice
Take the assessment to whoever owns the business case and ask what the smallest thing is that would justify the project. Often it's a fraction of the original scope. Write it down as a list of user-visible behaviours, not features by name, and cut everything that doesn't serve it.
You should finish with a definition of done that a non-engineer can verify by using the product.
4. Stabilise before adding features
Fix the build, the deployment pipeline, the defects users actually hit, and basic monitoring. Leave refactoring for later. Krononsoft, another rescue vendor, ranks fixes that affect users or revenue first and structural improvements last, and says it can work alongside an existing internal team. That matches how we'd order the work, though it's one vendor's account of its own practice.
The end state is a project that deploys on demand and fails visibly. Only then does it make sense to build the first slice.
5. Choose who does the rescue
You have three options: the current vendor on a recovery plan, a specialist rescue firm, or senior engineers you hire and direct yourself. The next section compares them. Pick on the assessment's findings, not on who's already in the room.
6. Set gates and a review date
Agree a continue-or-stop review every two to four weeks, a written definition of done tied to step 3, and a date after which emergency mode ends. This is our judgment, but a rescue with no end date turns into a permanent state of emergency with a monthly invoice.
At each gate, the question is the same: is the project closer to the first release than it was last time? If the answer is no twice in a row, stop and reassess instead of extending.
Three ways to staff a rescue, and what each costs you
| Option | Fits when | Main risk | Terms to ask for |
|---|---|---|---|
| Current vendor on a recovery plan | The assessment finds the team capable and the failure was scope or process | Conflict of interest: they're grading their own work | A written plan with milestones, no payment for rework of defects, a named senior |
| Specialist rescue firm | You have no one in-house who can direct the work | Open-ended hours, and a sales team that differs from the delivery team | Paid assessment first, fixed-scope phases, stop-loss gates |
| Senior engineers you hire and direct | You have a technical lead, or can hire one, to run it | You carry the management load | Short trial, no minimum hours, replacement if it isn't working |
We haven't found a reliable price list. What you pay depends on the state of the code, whether tests exist, how much of the scope is still valid, the size of the team and how long it takes to reach a first release. To cap exposure, buy the assessment separately, fund the work in fixed phases, and keep every phase behind a gate. These are our terms of engagement advice, not an industry rule.
If the budget conversation is the hard part, the guide to explaining technical debt to a non-technical CEO shows how to turn it into a dated ask sized in engineer-weeks.
Red flags when choosing a rescue vendor
Most of these are our judgment, drawn from how rescue engagements tend to go wrong. Two echo DOOR3's warnings about vendors who promise to know every technology and vendors who cut discovery to save cost.
- A fixed price quoted before anyone has seen the code.
- A refusal to give assessment findings in writing, or a report you can't take elsewhere.
- Assessing and building by the same party, with no way to walk away after the assessment.
- A pitch that the team is equally expert in every technology.
- Discovery cut back to save cost or time.
- Only the senior person appears on sales calls, and you never meet who'll do the work.
- Open-ended time and materials with no gates.
- Delivery dates promised before anyone has read the code.
The pattern behind most of these is the same: the vendor is selling certainty it can't have yet.
What this means for who rescues your project and on what terms
The decision this week isn't "which rescue firm". It's whether to buy an independent assessment first, and to keep it separate from the build. That single separation protects you from a bad outcome we think is common: a recommendation shaped by who gets the work.
If you're a non-technical founder who has been relying on the vendor's word, the assessment is your first piece of evidence the vendor didn't write. If you're a CTO who inherited the project, it's the document you take to the board. Either way, prefer short gated terms over open-ended hours on a project that's already over budget, and ask the party assessing whether they'd recommend a restart if the evidence pointed that way. (All of this is judgment, not a sourced rule.)
Once you know which option fits, check the terms before signing. The guide to how to evaluate a nearshore vendor in 7 steps covers replacement and notice terms.
Hiring senior engineers for a struggling project through HighCircl
HighCircl isn't a rescue firm. It supplies senior engineers you direct yourself, which is the third option above. It matches a shortlist of 3-5 within 72 hours, from Poland, Hungary, Slovakia, Serbia, Slovenia, Romania and Spain. There's no minimum hour commitment, no subscription and no recruitment fee, and an engagement that isn't working gets a replacement at no additional recruitment cost. Rates run €45-105/hr ($50-115/hr), with a 20% margin that's capped and shown on top of the engineer's earnings. See the HighCircl hire page for the roles it covers.
FAQ
How do I know if my software project is beyond saving?
Run the four questions: does it build and deploy from a clean checkout, do the tests mean anything, is the domain logic right, is the scope still valid. Wrong domain logic with a stale scope is the clearest sign you're past saving. A broken build or missing tests alone usually aren't. That's our judgment, not a measured threshold.
Is it cheaper to rescue a software project or rebuild it?
It depends on how much survives the assessment, and we haven't found a reliable industry figure that answers it. Rescue costs less when the domain logic and the core structure are sound. It costs more than it's worth when you'd spend the budget propping up code you'd replace anyway. Pay for the assessment first, then price both against the same first releasable slice.
How long does a software project rescue take?
We haven't found a trustworthy industry-wide number, and a vendor quoting one before assessing your code is guessing. The assessment tells you: it produces a list of what blocks a release, and the time is the sum of that list. Plan in two-to-four-week gates rather than a single end date.
Should the original vendor be the one to fix it?
Sometimes, but treat the conflict of interest as real. They may have an incentive to call defects scope changes and to avoid recommending a restart. If you keep them, get a written recovery plan with milestones, don't pay twice for rework of their own defects, and have an independent party read the assessment.