Taking over software nobody maintains: my first 10 days
The product still earns, the developer is gone, and every bug report waits. This is how I start a rescue, before a single line gets fixed.
Days 1–2: read before you touch
The urge on day one is to start fixing. Resist it. Get access to everything first: the repository, hosting, database, domain and any third-party keys. Then run the app locally and write down what you find.
Days 3–4: reproduce the loudest bugs
Rank bugs by business impact, not technical interest. A bug you can't reproduce is a guess, so each one gets exact steps before anyone touches the code.
Days 5–7: build a safety net
Add error logging and alerts, take a backup and prove you can restore it, and make deploys versioned so a bad release can be rolled back in minutes. This is what turns an app nobody dares to touch into one that is safe to change.
Days 8–10: fix three, document the rest
Fix the top three bugs, then write a short handover: how the system runs, where the risks are, and the remaining issues in priority order. From there you can keep me on a retainer, or give the product to a new team with real documentation.
Freelance full stack engineer in Jakarta. I build web and mobile apps, rescue unmaintained software and join busy teams.