The first two days on a codebase nobody can explain

A surprising share of my work starts the same way: a founder has a product that earns money, a repository they cannot read, and a developer who is no longer answering. The instinct is to start fixing. The instinct is wrong. For the first two days I do not change behaviour at all.

Day one is provenance. Can I run it locally? Can I deploy it? What happens on deploy — who or what runs migrations, where do secrets come from, is there a step that only ever happened on someone’s laptop? Undocumented deploys are the single most common thing standing between a client and a working release, and they cost nothing to discover before you need them at midnight.

Then I read the money path. Not all of the code — the path from a user’s intent to a row in the database that the business cares about. Signup, checkout, booking, whatever it is. Everything else can stay a mystery for a while.

The second day I write down what I am afraid of. Literally a list: this cron job has no logging, this table has no foreign key, this integration retries forever. Ranked by what happens to the business if it fails on a Saturday. That list, not the code quality, is what I send the client — and it is usually the first time anyone has told them what they own in language they can act on.

Only then does work start, smallest reversible change first, with a way to verify it. Rewrites get proposed in month three if at all. Almost every codebase I have been handed was better than it looked; it was just unlit.