You inherited a product: the code audit before you continue

Inheriting a software product can be a daunting task. The developer who originally built the software may have moved on, the contract with the agency may have ended, or the code may have passed through too many hands for anyone to be certain of its functionality. Before spending money on making changes, it's crucial to conduct a code audit to understand the health of the codebase.

A code audit involves a thorough review of the code and the architecture, which provides a written report on what to keep, what to fix, and what to rewrite. This article explains the importance of a code audit when inheriting a product, as the decision to make changes without conducting an audit is often the more expensive one. A code audit is not just about reviewing the code; it also examines who owns the accounts, the cost of running the product, and the existing risks.

In most cases, the recommendation to rewrite everything from scratch is frequent and costly. However, there is usually a core worth preserving, and three concrete issues that need fixing. An inherited product usually arrives in one of four scenarios: the developer left and left no documentation, the agency finished the project but disappeared, the code drifted over the years with many small changes breaking old ones, or the product was purchased without any prior review.

In all these scenarios, the starting point is the same: a product in use by users, with the team unable to answer basic questions about its cost, downtime, data security, or the effort behind new features. Conducting a code audit addresses these fundamental questions, making it a crucial first step before asking for new features.

The cost of an audit is far less than the expense of developing blindly for the first month. The full guide to conducting a code audit, including implementation, trade-offs, and post-production insights, is available on the author's blog.