Inheriting a codebase: the two-week audit that saves six months

A half-finished product usually arrives with two conflicting pressures. The business wants it live as soon as possible, because money has already been spent. And nobody fully trusts what is there, because the team that built it is gone.

The instinct is to hand it to a new team and say “finish it”. The new team then spends its first months discovering what the previous one left behind, on your budget, and often concludes that large parts need rebuilding — after they have already tried to extend them.

A short, structured audit before any new development avoids most of that. Two weeks is enough for a typical business application. Here is what it should cover, in the order that matters.

Days 1–2: access and ownership

Before anyone reads a line of code, establish what you control. Rescue projects stall on access far more often than on technical problems.

Make a list and confirm, for each item, who is the account owner — not who has a login:

• source code repositories and their organisation or workspace
• the domain name and DNS provider
• hosting and cloud accounts (and the payment method attached)
• app store developer accounts, signing keys and certificates
• databases and their backups
• third-party services: email delivery, payments, maps, analytics, error tracking
• the password manager or wherever credentials were kept

If the previous vendor registered any of these in their own name, that is the first problem to solve, and it may take longer than the code review.

Days 2–4: can it be built and deployed from scratch?

Take the repository, a clean machine and whatever documentation exists, and try to build and deploy the application to a fresh environment.

This test answers more questions than any document review:

• Are all the dependencies declared, or do some only exist on the old team’s laptops?
• Are secrets hard-coded, or configured per environment?
• Is there a deployment process, or did someone copy files to a server?
• Does the version in the repository match what is running in production?

If the application cannot be rebuilt from its own repository, everything else in the audit is provisional. Fixing that is always the first milestone.

Days 4–7: architecture and data

Now the reading starts. The goal is not to grade the code but to map it.

• Architecture map. What are the main parts, how do they talk to each other, and where does business logic actually live?
• Data model. Do the main entities match how the business works? A data model that misrepresents the domain — orders that cannot have more than one delivery, customers that cannot belong to two companies — is the most expensive thing to fix later.
• Integrations. Which external systems are called, how, and what happens when they fail?
• Security basics. Authentication and permission checks, secrets in the repository history, known vulnerabilities in dependencies, and how personal data is stored.

Days 7–9: quality where it counts

Sample rather than read everything. Pick the two or three flows that matter most to the business — checkout, invoicing, scheduling — and follow them through the code.

Look at:

• whether there are automated tests for those flows, and whether they pass
• error handling: what the user sees and what gets logged when something fails
• how hard it would be to make one realistic change, such as adding a field to an order

That last exercise is revealing. If a small change touches fifteen files and breaks something unrelated, you have learned more about maintenance cost than any metric would tell you.

Days 10–12: the report

The output is a written recommendation per module, in three categories:

• Keep. Works, reasonably structured, can be extended.
• Refactor. The approach is sound, but specific problems must be fixed before building on top.
• Rebuild. Cheaper to replace than to repair, with the reason stated.

Each recommendation should come with a rough effort range and the risk of not acting.

Which findings justify a rewrite

Rewrites are expensive and emotionally attractive. New teams almost always want one. The findings that genuinely justify rebuilding a module are narrower than you might think:

• The data model is wrong for the domain, and the business depends on the part that is wrong.
• The application cannot be built, deployed or secured in its current form, and fixing that would touch most of the code.
• The framework or platform is no longer supported, with no realistic upgrade path.
• Security problems are structural — for example, permissions enforced only in the user interface.

Findings that usually do not justify a rewrite on their own:

• The code style is inconsistent or “ugly”.
• There are few tests. Tests can be added around the parts you are about to change.
• The framework is older but still supported.
• The new team would simply have made different choices.

When the previous vendor has gone quiet

If the former vendor is not responding, work through access in this order:

1. Check your contract for IP assignment and handover obligations. A clear clause makes every conversation that follows shorter.
2. Send a formal written request listing exactly what you need handed over, with a deadline. Keep it factual.
3. Recover accounts registered in your company’s name through the providers’ own recovery processes. Domain registrars, cloud providers and app stores all have procedures for proving ownership, and they take time — start early.
4. Preserve what is running. Take backups of production data and, where you legitimately can, of the deployed application, before anything changes.
5. Get legal advice if assets are registered to the vendor and they will not transfer them. That is a contractual matter, not a technical one.

How we run rescues

At ANASBRENT a product rescue always starts with a written audit, delivered as its own short engagement, before anyone quotes for further development. The report is yours whether or not you continue with us. If you have inherited something that needs an honest assessment, tell us where it stands.