Insights · 6 min read
Inheriting someone else's codebase: what to do in the first 30 days
By Austin Hunter ·
We've taken over live products built by other teams, and the temptation on day one is always the same: "this would be easier to rewrite." Sometimes that's true, but you can't know until you understand what's there. This is the order we work in for the first month.
Week 1: access and inventory
- Get admin access to the code repository, hosting, database, app stores, domain, payments and email services, in the owner's name.
- Write down every service the app uses and what it costs each month.
- Find out how the app is deployed today, and whether that can be done from a clean machine.
- Make and test a backup before touching anything.
Week 2: read before you write
- Run the app locally and make a small, harmless change end to end, from code to a test deploy.
- Map the data: what's stored where, and who can read and write it.
- Read the error logs and support inbox for the last few months. That's where the real problems are.
- List secrets and keys, and where each is stored.
Week 3: make it safe
- Add error reporting and uptime alerts if they're missing.
- Fix anything that exposes data or money: open database rules, leaked keys, payment logic that trusts the app instead of the payment provider.
- Clear any store or platform deadlines that are close.
Week 4: plan, with the owner
Write up what works, what's risky and what to change first, each with an estimate. Then agree on a routine: how changes are reviewed, tested and released, and who approves production changes. Only now is it fair to talk about a rewrite, and usually the answer is to improve the parts that hurt and leave the rest.
How we do it for clients
Our $990 Production health check covers weeks one to three as a fixed-fee, read-only review with a ranked fix list. A care plan keeps it running afterwards.