Taking over someone else’s codebase: the first two weeks

The agency stopped answering. The developer who built it has left. The product works and nobody is willing to change anything in case it breaks.

This is a normal week for us, and the first two weeks of it are almost entirely about looking rather than changing. That ordering is deliberate, and it is the part clients find hardest, because the instinct when something is broken is to fix it.

Here is what those two weeks actually contain. Not because the sequence is proprietary, but because knowing it tells you what to ask of anyone you hire for this — including whether they intend to do it at all.

Days one and two: getting the keys

Frequently the hardest part of the whole engagement, and almost never the part anyone plans for.

The list is longer than people expect: the source repository and its full history, hosting and server access, the domain registrar, the database, the deployment pipeline, third-party service accounts, API keys, payment provider access, app store accounts, and the signing certificates. For a mobile product the certificates matter enormously — without them you cannot ship an update to the app your users already have, and recovering them is sometimes impossible rather than merely slow.

Two things we do immediately. First, write down what exists and who holds it, because nobody has that list and its absence is why this situation arose. Second, establish what is missing, because that determines what is even possible.

If a previous agency has gone quiet, what you can recover depends on where things are hosted and what your contract says. We have done this recovery before and it is often better than people fear — but it is work, and it belongs at the start rather than being discovered in week three.

Day three: can anyone run it

Before reading a line of the code, get it running from a clean checkout following only what is documented.

This is the fastest way to learn the true state of a project. If it comes up in an hour, somebody cared. If it takes three days of guesswork, that tells you about everything else you have not looked at yet. And if it cannot be done at all without the original author, then you do not have a maintainable product, whatever the code quality — because nobody can safely change something they cannot run.

Deployment gets the same treatment. How does a change reach production? If the answer is that one specific person did it from their laptop, that is a continuity risk sitting on top of whatever else we find.

Days four to seven: the structured read

Now the audit proper, in a fixed order, worst-consequence first.

Dependencies and licences. Authentication and, separately, authorisation — including the single most revealing test there is, which is requesting a protected resource directly with a token that should not have access. The data model, read before any application code. Concurrency, by finding the places two users could collide. Error handling, by reading what the catch blocks actually do. Tests, by running them rather than counting them.

We have published that checklist in full, including the parts you can run yourself: how to audit a codebase before you build on it. It was written for AI-generated code and it applies to any inherited system.

One discipline matters here: we change nothing during this week. The temptation to fix something small while reading is strong and it corrupts the picture. You want to know the state of the system as inherited, not as improved by whoever read it first.

Days eight and nine: what the business actually depends on

The part most technical audits skip, and the part that determines which findings matter.

We ask which features earn money, which are used daily versus annually, what has broken before and what happened, and which parts people have quietly stopped using. We talk to whoever handles support, because support tickets are the most honest documentation any product has.

This is what turns a list of technical problems into a ranked one. A serious flaw in something nobody uses is less urgent than a modest one in checkout. Without this step every finding looks equally important, which is the same as none of them being important.

Day ten: the written report

Everything found, ranked by what it costs you rather than by how much it annoyed an engineer. Each item with what it costs if nothing is done, what it costs to fix, and whether that cost rises with time — because some things compound and some sit there harmlessly, and spending money on the wrong category is the usual mistake.

It says plainly what is sound, which is as useful as what is broken. It includes what is missing and unrecoverable, if anything is. And it ends in a recommendation, including when that recommendation is to leave it alone or to stay with your current arrangement.

The report is yours regardless of what happens next, including if you take it to a different team.

Days eleven to fourteen: the conversation, then stabilisation

We walk you through the report live, because the decisions get made in conversation rather than in a document. Then, with your agreement, the urgent things only — a security exposure, a data integrity problem, anything actively losing money.

Not improvements. Not refactoring. Not the thing an engineer would most enjoy fixing. The relief people feel at the end of a takeover almost always comes from this narrow band of work, and doing it before the audit would have meant guessing at which band it was.

What we deliberately do not do in two weeks

• Promise a timeline for the whole thing. Any date given before the audit is invented. We will give you one after.
• Propose a rewrite. It is the most expensive option available and it is right far less often than it is proposed. If it genuinely is the answer, that conclusion comes with evidence and a phased plan, not in week one.
• Add features. However small the request, changing a system nobody understands yet is how a recoverable situation becomes a worse one.
• Tidy anything. Renaming, reformatting and reorganising all make the next person’s archaeology harder, not easier, and none of it is what you are paying for.

What to ask whoever you hire

If you are taking quotes for a takeover, the useful question is: what will you do in the first two weeks, and what will you have changed by the end of them?

Anyone willing to quote a full takeover without looking at the code is guessing, and the number they give you is one they will have to revisit. The audit is what makes an estimate real. We will not take this work without doing it first, and that is for your protection more than ours.

If this describes your situation

Send us what you have — a repository, a login, or just a URL. We will tell you what we find and what we think it would take, before anyone signs anything.

Related reading

• Project Takeover and Modernisation — the full engagement
• The real cost of technical debt — which findings actually compound