02
Existing Codebase Rescue
You've inherited something — from a contractor, a co-founder, a previous team, or an AI session six months ago. It runs, mostly. Nobody can tell you how, and everyone is nervous about touching it.
What this usually looks like
- No documentation, no tests, and nobody left who wrote it.
- A deployment process that lives in one person's memory.
- Dependencies years out of date, and upgrading breaks things.
- Code that is clearly doing something important, unclearly.
- A quote for a full rewrite that you suspect is the wrong answer.
What I actually do
- 01
Map it before changing it
I work out what the system is, what it talks to, where the data lives, how a request flows through it and how it gets deployed. Nothing gets edited during this part.
- 02
Find the load-bearing parts
Every inherited codebase has a handful of places where the real risk sits — auth, payments, data migrations, anything with a cron. I identify those specifically, because they change how everything else should be approached.
- 03
Separate risk from mess
Ugly code that works is not the same problem as tidy code that loses data. I'll tell you which is which, so effort goes where it changes outcomes.
- 04
Give you a sequence
Not a wish list — an order. What to do first, what it unblocks, and what can be safely left alone indefinitely.
How long it takes
Two to four days for a codebase of ordinary size, depending on the requirements — several repositories, or a system spread across services, takes longer. Implementation is scoped separately, once you’ve seen the map and can decide what’s worth doing.
Questions about this
Can you take over an existing codebase?
Yes. I start by understanding the system before changing anything — dependencies, data model, auth, deployment, and the parts that are load-bearing. Then I’ll tell you what I found before I start editing.
Do I need to rebuild my application?
Usually not. Rewriting is the most expensive option and it’s rarely the one the code actually calls for. I’d rather find the specific things that are broken and fix those.
What do you need from me?
Less than you’d think. A repository or a deployed URL, some idea of what’s broken, and access to whatever is failing — logs, the hosting dashboard, an error message. If you don’t have all of that, send what you do have and I’ll tell you what else I need.
Your AI-built app doesn’t need another prompt.
Sometimes it needs an engineer.
Send the messy version. That’s usually the useful version.