Auditing an inherited product starts with who owns the accounts and what it costs to run

The three things the post puts at the top of an audit all sit outside the source tree. Who owns the hosting, the domain and the store listings is a contract question. In the agency case the post describes, the contract does not cover what happens to the accounts once the engagement ends ^[7]. What the product costs to run per month sits in a billing console, and the post's premise is that the inheriting team cannot state the figure ^[8]. The third item is live risk. The examples given are an access key published in the repository, a database with no backups, and a service that stopped receiving security updates, and none of them appears on anyone's to-do list. Any one of them, the author says, can cost the owner the whole product ^[10].

The mildest case in the post is the solo developer who kept everything in their head, left no documentation, and still answers messages for a while after going ^[7].

The author has an interest and declares it. "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," the author wrote ^[5]. The service being recommended is the author's own, so this is an interested argument; the checks it describes can still be run against your own repository.

The estimating claim is the part an engineering manager can test this week. In code you do not know, the post says, a twenty-line change can be twenty lines or three weeks, and anyone who quotes a price without reading the code is guessing ^[9].

"Rewrite everything from scratch" is, according to the post, the most frequent recommendation from whoever arrives new. It is also the most expensive one for the owner, because there is almost always a core worth keeping and three concrete things to fix ^[6]. In my view part of the appeal is estimating convenience: nobody gets caught being wrong about the cost of code that is going to be deleted. The alternative output is narrower and harder to write. The post is specific that the audit ends in a document, not a conversation ^[3].

"An audit costs a fraction of what the first month of blind development costs. That is the entire argument," the post says ^[12]. There are no figures on either side of that comparison ^[17]. For it to hold on a particular product, the audit fee has to be small against what a first month of development actually costs at your rates. The written verdict also has to be specific enough that the next contractor prices the work from the document instead of re-reading the repository ^[2].

The piece ran twice on dev.to, in Spanish and in English, under the same author handle, each version pointing readers to the language-matched half of the author's own blog for the rest ^[13][14]. The two posts are one practitioner's account, and each is the first half of it ^[15].