Your first 90 days with a codebase you inherited

The temptation

You inherit a system and your first instinct is to tidy it. Resist it. You don't yet know which strange parts are mistakes and which are load-bearing.

Weeks 1 to 2: learn how it runs

Get the thing running on a fresh machine, from the instructions alone. Every missing step you hit is a finding. Find out how it's deployed, who has access, where the secrets live, and what happens when it breaks at 2 a.m. Then read the monitoring and the last six months of incidents, which tell you more than the code does.

Weeks 3 to 6: make it safe to change

Add tests around the parts that matter most to the business, such as billing, sign-in and data export. They don't have to be elegant. They only have to tell you when behaviour changes. Make deploys boring: one command, repeatable, with a way to roll back.

Weeks 7 to 12: start improving, in small pieces

Now you can fix things. Pick the changes that remove the most risk or the most friction, and ship them one at a time. Keep a short written list of what you found, what you changed and what you chose to leave alone, and why.

What to do in the first month

1. Run it from scratch. On a clean machine, following only the written steps.
2. Map access. Who can deploy, who can see production data, which accounts are shared.
3. Read the incident history. Look for repeats.
4. List the five scariest areas. The ones nobody wants to touch, and why.
5. Write tests around the top two before changing anything.