Software Project Rescue: We Take Over Failing Projects
A project that has overrun, stalled, or been abandoned. Before anyone promises you a date, the job is to establish what actually exists — and the answer is usually better than you fear and worse than you were told.
Discuss your projectSigns you need a rescue
One is enough to justify an audit. Several together usually means the project has been drifting longer than has been admitted.
- The completion estimate has been "about two more weeks" for several months.
- You cannot get a working build without the original developer doing it for you.
- Nobody can tell you where the code is, or the repository you were given does not build from a clean checkout.
- Every new feature breaks two existing ones, which means there are no tests and no one is willing to say so.
- The developer has gone quiet, left, or is now unreachable.
- It works in a demo and fails on real data, real volume, or a real connection.
- You are paying a monthly retainer and cannot name what changed last month.
- A deadline you cannot move is approaching and nobody will commit to meeting it.
- Costs have exceeded the original quote with no corresponding change in scope.
What we do
- 01
Audit, before any promise
A fixed-scope week or two: does it build from a clean checkout, what is the dependency and vulnerability position, is there any test coverage, how is it deployed, where are the credentials, and is the data model sound. You get a written report and a straight assessment of how much of what you have paid for actually exists.
- 02
Secure what you own
Often more urgent than the code. Repository ownership moved to you, cloud and third-party accounts reissued under your billing, domains and DNS confirmed in your name, credentials rotated, and the previous developer's access revoked. This gets postponed and is painful to do later.
- 03
Stabilise before extending
Get it building reproducibly, get a deployment pipeline in place, fix what is actively broken, and put monitoring on it so you find out about failures before your customers tell you. A system that can be deployed at all is the precondition for everything else.
- 04
Establish the real position
A revised scope and estimate for what remains, based on the code rather than on the original proposal. This is frequently the uncomfortable part, and it is the number you can actually plan against.
- 05
Then build
Normal delivery, in reviewable slices, with the scope and the defect-versus-change-request distinction written down this time.
Fix, refactor, or rebuild
A rebuild is the most profitable thing we could recommend, so you are entitled to the reasoning in writing and to a second opinion.
| When we recommend it | What it means | |
|---|---|---|
| Fix in place | It builds, the architecture is reasonable, the problems are specific defects and neglect | Fastest and cheapest. More audits end here than clients expect |
| Refactor one layer | Mostly sound, but one area — data access, authentication, the front end — blocks every change | A contained piece of work with a visible payoff, then normal development |
| Rebuild | No source, an abandoned framework, or a data model wrong in a way that touches everything | A real project. We reuse the database, API and designs wherever they are sound, so it is rarely everything |
Where we recommend a rebuild we will also say what it would cost to limp along instead, because that is sometimes the right commercial choice even when it is not the right engineering one.
Common questions
Tell us what you need
Describe the problem and we will come back with scope, timeline, and a rate. No obligation to proceed.
Get in touch