Taking Over an Existing Codebase: How a Software Rescue Actually Works
Taking over an existing codebase starts with a technical audit — typically one to two weeks — that establishes what runs, what is documented, what is load-bearing and what needs rework. Only then can anyone quote the ongoing work honestly. Expect to pay for that audit: any firm quoting a full rebuild price before reading the code is guessing.
Half-finished software projects are more common than anyone advertises. A developer moves on, an agency relationship breaks down, a contractor finishes their notice period, or a build simply stalls somewhere past the point where stopping feels affordable. What you are left with is an asset you paid for and cannot currently move forward.
The good news is that this situation is routine for teams that do it often. The bad news is that the first advice you get is frequently “rebuild it from scratch”, which is sometimes right and frequently just easier to quote.
- A stalled build is rarely worthless. It is an asset of unknown condition, and finding out costs far less than assuming.
- Start with a technical audit, typically one to two weeks. Anyone quoting a full rebuild before reading the code is pricing an average project, not yours.
- Rebuild versus refactor should be decided per component, not as one verdict for the whole system.
- Secure the repository with its commit history, and administrative ownership of every account, before the old relationship ends.
- A rebuild discards every business rule nobody remembers — usually the ones added because something went wrong in production.
Why “rebuild from scratch” is so often the first answer
Reading someone else’s code is harder than writing your own. Understanding an undocumented system means reconstructing decisions nobody wrote down, and it is genuinely slower and less pleasant than starting fresh. So the incentive to recommend a rebuild is real, and it is not always cynical — it is sometimes just the path of least resistance for the person quoting.
But a rebuild throws away every business rule already encoded in the system, including the ones nobody remembers. Those edge cases were usually added because something went wrong in production. Starting again means rediscovering them the same way.
Our own guide on rebuild, refactor or replace goes deeper on that decision. The short version: it should be an outcome of the audit, not an opening position.
What a technical audit actually looks at
A useful audit answers questions you can act on commercially, not just technically:
- Does it build and run? Sounds trivial. A surprising number of handovers arrive without working local setup instructions, and reconstructing the environment is the first real cost.
- What is the test coverage? Not as a vanity metric, but because tests are executable documentation of intended behaviour. A system with meaningful tests can be changed safely; one without cannot.
- Where is the business logic? If the rules live in one well-defined layer, the system is workable. If they are scattered through controllers, views and database triggers, that drives both cost and risk.
- What are the dependencies, and are they maintained? A framework two major versions behind, or a package abandoned upstream, is a security and cost problem with a deadline attached.
- How does it deploy, and who holds the keys? Hosting, domains, DNS, certificates, third-party API accounts. This is where handovers most often break down commercially rather than technically.
- What is genuinely load-bearing? The distinction that matters most: which parts are working and should be preserved, versus which parts merely exist.
What the audit should produce
You should finish the audit holding documents you own and could hand to a third party:
- A plain-English assessment of the system’s condition, written for a decision-maker rather than a developer.
- A risk register — security issues, unmaintained dependencies, single points of failure — ordered by urgency.
- A recommendation on rebuild versus refactor per component, not for the whole system as one verdict. Most real answers are mixed.
- An estimate for getting to your next meaningful milestone, with the assumptions written down.
If an agency quotes you a full rebuild price before anyone has read the code, they are not quoting your project. They are quoting an average one.
| What the audit finds | Usually points to | Why |
|---|---|---|
| Meaningful test coverage, current framework | Refactor | Behaviour is documented in executable form, so it can be changed safely and incrementally |
| No tests, unsupported framework, simple business rules | Rebuild | Nothing protects you from regressions, and there is little encoded knowledge worth preserving |
| No tests, but complex and long-lived business rules | Refactor, carefully | The edge cases are the asset. Rebuilding means rediscovering them the way they were found the first time — in production |
| Works, but cannot be deployed or built locally | Stabilise first | Neither path is safe until the system can be built, deployed and rolled back reliably |
Getting the handover right
Whatever the state of the relationship with the previous team, secure these before it ends. Recovering them afterwards is far harder:
- The full repository, with history. Commit history is genuine documentation — it explains why things changed. A zipped folder of current files loses it.
- Administrative ownership of every account: hosting, domain registrar, DNS, SSL, third-party APIs, app store listings, error monitoring. Ownership, not just access.
- Environment variables and secrets, transferred through something safer than email.
- A written statement of what is incomplete — even informally. Ten minutes of honesty here saves days of archaeology.
- Confirmation in writing that you own the code, if your original contract left it ambiguous.
Frequently asked questions
Can you take over a project another agency started?
Yes — this is a large part of what we do. We start with a short technical audit to understand what is genuinely load-bearing versus what needs rework, then agree a plan before touching production. We are equally comfortable extending a codebase in a stack we did not originally choose.
How much does it cost to take over an existing codebase?
The audit is a defined piece of work and can be fixed price. The work that follows depends entirely on what the audit finds, which is exactly why it comes first. Anyone quoting the full engagement before reading the code is pricing an assumption, not your system.
What if the previous developer will not hand anything over?
If you own the hosting and the domain, a great deal can be recovered from the running system, though it is slower and more expensive than a clean handover. Where code ownership is genuinely disputed, that becomes a contractual matter rather than a technical one — which is why ownership should be confirmed in writing at the start of any engagement.
Is it always cheaper to fix what exists than to rebuild?
No. Sometimes a rebuild genuinely is the right answer — typically when the framework is unsupported, there are no tests, and the business rules are simple enough to restate confidently. The point is that this should be a conclusion the audit reaches, not the opening recommendation.
How long does a technical audit take?
Usually one to two weeks depending on the size of the system. Long enough to run it, read the load-bearing parts and test the assumptions; short enough that you are not paying for analysis you could have spent on the fix.
The practical takeaway
A stalled build is rarely worthless. It is usually an asset with unknown condition, and the cost of finding out is far lower than the cost of assuming — in either direction. Get the audit, own the accounts, and make the rebuild-or-refactor decision per component with evidence in front of you.
If you have a project that stalled and you want an honest assessment of what you are holding, send us the details. We will tell you if a rebuild is genuinely the right answer.
