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.
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.
Keep reading
That is the first half. The full walkthrough — with the rest of the implementation, the trade-offs and the things that only show up in production — is on my blog:
Read the full post on ramonchancay.me →
Originally published at www.ramonchancay.me/blog/code-audit-inherited-product.
Top comments (0)