You inherited a product: the code audit before you continue

Inheriting a product means being left in charge of software somebody else built: the developer moved on, the agency’s contract ended, or the code passed through so many hands that nobody knows for certain what it does any more. You have a product that works—or half works—and no reliable way to tell how healthy it is inside. A code audit is the answer to that question before you spend the first dollar on changes: someone reads what is there, holds it against what your business needs, and hands you a written verdict on what to keep, what to fix and what to rewrite. I am writing this because it is half of my work, and because the decision taken without an audit is almost always the expensive one.

TL;DR

• Before asking for new features on an inherited product, you need to know what you have. That is answered by an audit of the code and the architecture that ends in a document, not in a conversation.
• The audit does not only review code: it reviews who owns the accounts, how expensive the product is to keep running, and which risks are already live. Several of the most urgent findings are never technical.
• "Rewrite everything from scratch" is the most frequent recommendation from whoever arrives new, and the most expensive one for you. There is almost always a core worth keeping and three concrete things to fix.

In this article:

• Fundamentals — What inheriting a product means · Why the first move is not writing code
• The audit — What gets reviewed · What the written verdict says · How long it takes and what comes after
• Deciding — Keep, fix or rewrite · The red flags · What to gather

What inheriting a product means

The cases almost always arrive in one of these shapes:

• The developer left. They worked alone, kept everything in their head, and left a repository with no documentation. Sometimes they still answer messages for a while; sometimes they don’t.
• The agency finished and disappeared. It delivered a version that worked on delivery day. Six months later nobody answers, and the contract says nothing about what happens to the accounts.
• The code drifted over the years. Nobody left: the product piled up small, urgent changes until every new one breaks something old, and nobody dares touch certain parts.
• You bought the product. You acquired a company or an app and the software came with it, without anyone on your side ever having reviewed it.

In all four the starting point is the same: there is a product your users use, and your team cannot answer basic questions about it. How much it costs to run per month. What happens if it goes down on a Tuesday at nine at night. Whether your users’ data is where it should be. How much real work sits behind the feature you want to add next month.

Not knowing those answers is not a management failure. It is the normal state of a product that changed hands without a handover. What is a failure is to keep building on top without resolving it.

Why the first move is not writing code

The natural reaction when you inherit a product is to ask for what you need: fix the bug users are reporting, add the screen a client asked for, ship the new version. It is reasonable, and it almost always goes wrong, for three reasons.

You don’t know what you are touching. In code you don’t know, a twenty-line change can be twenty lines or three weeks. Nobody can really quote you without having read what is there, and whoever gives you a price without reading it is guessing.

You don’t know what is at risk right now. The most urgent things in an inherited product are rarely the ones visible from the outside. An access key published in the repository, a database with no backups, or a service that stopped receiving security updates appear on nobody’s to-do list, and any of the three can cost you the whole product.

You don’t know whether it is worth continuing with it. Sometimes the honest answer is that the code is not worth what it costs to maintain, and that is a business decision you need to take with information, not after investing six months in improving it.

An audit costs a fraction of what the first month of blind development costs. That is the entire argument.

What a code audit reviews

There are eight areas, and the order matters. The first ones are not technical, and that is deliberate: a flawless diagnosis of the code is worth nothing if the app store account turns out to be registered to someone who no longer answers.

Area	The question it answers
Ownership and access	Who owns the code, the domains, the accounts and the keys today?
Infrastructure and cost	Where does the product live, and what does it cost per month to keep it running?
Architecture	How is the system split up, and which parts depend on which?
Code	How readable and modifiable is it, and where is the mess concentrated?
Dependencies and versions	How old is what it runs on, and what no longer receives updates?
Data and security	Where is your users’ data, who sees it, and are there backups?
Releases and environments	How does a new version go out, and how long does it take? Can it be rolled back?
Tests and monitoring	Does anything warn you when it breaks, or do the users find out first?

None of these questions is answered by looking at the product from the outside. They are answered by reading the repository, getting into the service accounts, and shipping a test release to see how hard it is. That last part gives the most information: if nobody can ship a minimal change in the first few days, that is already a finding.

The full route, in the order it happens:

Note that the last box is yours. The audit does not decide: it orders the information so that you can, including the option of not continuing with whoever wrote it.

What the written verdict says

The deliverable has to be a document, not a call. It has to be readable without whoever wrote it in the room, because its real use shows up later: when you show it to a partner, to an investor, or to the next vendor quoting the work.

Ask for these four parts:

1. Overall state, in one page. What the product is, what it is built on, how healthy it is and what the main recommendation is. Written so that someone who does not program can follow it, because that person is usually the one who signs.

2. Risks, ranked by urgency. Each one with what can happen if it is left alone and how much work it takes to address. Ranked by potential damage, not by technical difficulty. Anything that can take the product down or expose data goes at the top, even if it is an afternoon’s fix.

3. Keep, fix or rewrite, part by part. The verdict is not a single judgement on “the code”. It is a list: this part is fine and stays, this one works but has to be fixed before it grows, this one is worth redoing, and this other one can be replaced by a service that already exists.

4. What it costs to run from here. The sum of what you pay every month in services, plus an estimate of the maintenance work the product will ask for as it stands. It is the number almost nobody gave you before, and the one that weighs most when deciding.

What the document should not have: adjectives about the work of whoever came before. The earlier code was written with the time, the budget and the information available back then, and whoever audits it knows none of the three. The verdict describes the state and the cost; it does not assign blame.

How long an audit takes and what comes after

One week, for a product of normal size. It is enough because the scope is bounded: read, try it, ship something minimal and write. It does not include fixing anything, and that is worth putting in writing before it starts. If something critical shows up along the way—an exposed key, data with no backups—it gets flagged the same day rather than saved for the report.

On price, one piece of advice: be wary of anyone who charges for the audit according to the size of the problem they find. When the fee grows with the severity of the diagnosis, the diagnosis stops being trustworthy.

After the report there are three roads, and all three are fine:

• You continue, with your team. You take the document and run it with the people you already have. It is the most common outcome when the product is healthy and what was missing was clarity.
• Someone takes the product on as its ongoing owner. Maintenance, releases, new features and a roadmap in plain language, with a fixed call every week. It is a monthly arrangement, not a closed project; how I work describes what a week like that looks like.
• You don’t continue with that product. Sometimes the verdict is that rebuilding costs less than sustaining, or that the product no longer matches what your business does today. Knowing that in a week is far better than discovering it in six months.

The most common recommendation after an audit is not to rewrite. It is to keep the core, fix three concrete things, and only then go back to building on top.

Keep, fix or rewrite: how it gets decided

“This is a mess, it has to be redone” is the first reaction of almost any developer facing someone else’s code. Sometimes it is true. Often it means that reading another person’s work is uncomfortable and starting from zero is more fun, and the one paying for that preference is you.

The criteria, part by part:

What I find	What I do
It works, it reads clearly, and it can be changed without fear	Keep it, even if it is not written the way you would have written it
It works, but every change takes three times longer than it should	Fix it: tidy that part before building on top
It solves something you can buy ready-made and cheap today	Replace it with that service
It sits on a technology that no longer receives updates	Migrate it, with a date, even if it works today
Nobody understands what it does and nobody dares touch it	Isolate it first, rewrite it afterwards, in pieces
The whole product is smaller than the cost of understanding it	Rewrite, and it is the only time rewriting comes out cheap

The underlying rule: a rewrite is justified by the cost of continuing, never by taste. And when it is justified, it is almost never all at once. You rewrite one part, ship it, check that the users are still there, and move to the next. A full rewrite means months with nothing new for your users while the old product, the one actually earning money, stops getting attention.

If your product is a mobile app or has an AI component, the criteria do not change but what gets reviewed does: mobile apps and AI products go into what each one looks at.

The most frequent red flags

These come up so often that it is worth checking them yourself, today, even if you hire nobody:

1. The accounts are not in your name. The domain, the app store account, the server or the email service are still registered to the previous vendor’s address. As long as that is true, your product is not entirely yours.
2. There is one key and everybody has it. A single access with full permissions, shared over chat, with no way to know who did what or to revoke it for one person.
3. There are no backups, or nobody has ever restored one. A backup that was never tested is not a backup. It is an assumption.
4. Nobody knows how to ship a release. If the only person who knew how to push a change is gone, your product is frozen even though the code is intact.
5. The dependencies have gone years without updates. The software your product runs on underneath receives security fixes. When those go unapplied for years, updating stops being routine and becomes a project.
6. Your users’ personal data is where it should not be. Full copies of the database on someone’s laptop, sensitive data unencrypted, logs keeping more than they need to.
7. There is no test environment at all. Every change is tested directly on what your customers are using.

The first three are resolved in days, without touching a line of code, and they are the ones that remove the most risk. If you do only one thing from this whole article, check whose name your accounts are in.

What to gather before it starts

Whoever reads your product will ask for this, whoever they are. Having it ready saves you the first week:

• The code. Read access to the repository, with its history. If there is no repository and the code only exists on the server, that can work too, and that fact is already part of the diagnosis.
• The service accounts. Where it is deployed, what database it uses, which third-party services it pays for. The owner’s passwords are not needed: separate read access is enough, and it is safer.
• The stores, if there is an app. Access to the App Store and Google Play accounts, even in the most limited role.
• Whatever documentation or contracts exist. Even if out of date. The contract with the previous vendor is mostly useful for what it says about who owns the code.
• An hour of conversation with whoever knows the business. What the product does for the company, what hurts today, and what has to happen over the next six months. Without that, the audit judges the code against an abstract ideal instead of against your reality.

If you are missing several of these, it is no reason not to start: recovering access is usually the first task in the plan, and it is exactly the kind of problem worth finding out about now. If the role behind this work is new to you, what a product engineer is explains what that person takes charge of beyond writing code.

Frequently asked questions

How much does a code audit cost?

It depends on the size of the product and on who does it; the usual arrangement is hourly, against a scope of about one week agreed before it starts. The useful comparison is not zero: it is what a month of blind development costs, because the alternative to auditing is not saving that money, it is spending it building on something nobody understood.

Can I ask for an audit if I don’t have access to the repository?

Yes, and it is a frequent case. It starts with recovering access, which usually means dealing with the previous vendor or with the platforms where the accounts are registered. While that moves along, everything visible from the outside can be reviewed: the product in use, the published apps, the domains, and whose name each thing is in. If the code turns out to be unrecoverable in the end, that is a verdict too, and it is better to have it before you plan the year.

Is it worth rewriting the product from scratch?

Almost never, and less often than it tends to be recommended. Rewriting means months with nothing new for your users while somebody rebuilds functionality that already existed, at the risk of losing details nobody documented and only the old code knew about. It is justified when sustaining what exists costs more than redoing it, when the underlying technology no longer receives updates, or when the product is so small that understanding it costs more than writing it. Even then it is done in pieces, shipping each one.

Is an audit useful if I want to stay with my current team?

Yes, and that is a legitimate use of the document. The verdict describes the state, the cost and the priorities; who executes that plan is a separate decision. It works to order the work with the team you already have, or to compare quotes against a common baseline instead of against vague descriptions. That is why the document has to be written to be read without whoever produced it.

What if the verdict says the product is not worth keeping?

A good report tells you, with the detail of why and with the cost of both alternatives: sustaining what exists or rebuilding it. It is the uncomfortable conversation in this work, and it is exactly the one you are paying for. A diagnosis that always ends in “this can be fixed, hire me” is not a diagnosis, so ask beforehand what happens if the answer is the other one.

Conclusion

An inherited product is not a technical problem, it is an information problem: you are making money decisions about something nobody on your side has read. An audit turns that into a document with ranked risks, a real monthly cost and a recommendation part by part, in one week of work.

If you have just been left in charge of a product, do it in this order: first check whose name the domain, the accounts and the stores are in, because that is fixed in days and removes the most risk; then get read access to the code and the services, even if you don’t yet know what to do with them; only then ask for the audit, and commit no new features or dates to your customers until you have it in hand. And when somebody proposes rewriting everything before having read what is there, ask them for the cost of the other option.