A common call I get: "Our developer left, the app needs changes, and nobody knows how it works." Sometimes the previous developer was good and simply moved on. Sometimes the project was rushed, undocumented and held together by hope. Either way, the business needs someone to take responsibility for a system they did not build.
The first instinct of many developers is to declare the old code terrible and propose a rewrite. Sometimes that is right. Usually it is not, and it should never be the first move. This is how I approach the first two weeks.
Day 1 to 2: Secure access and ownership
Before reading a single line of code, find out what the business actually controls:
- Source code: where is it? Is the repository in the company's account? Is the latest code even there, or only on the old developer's laptop?
- Servers and hosting: who has the login? Which provider, which account?
- Domain and DNS: whose account? When does the domain expire?
- App store accounts: are the apps published under the company's developer accounts?
- Third-party services: email, SMS, maps, payment gateways, analytics, error tracking. Which accounts, whose cards pay for them?
- Secrets: database passwords, API keys, signing keys for the mobile apps.
Write it all down in one document. Move anything held personally by the former developer into company accounts, and rotate credentials that are shared or unknown. Losing the Android signing key or the domain can be far more damaging than any bug.
Day 2 to 4: Get it to build and run
The next goal is to build and run the system from source, outside production:
- Clone the code and try to build every part: backend, web app, mobile app.
- Note every missing piece: undocumented environment variables, private packages, outdated tooling, a database schema that only exists in production.
- Get a local or staging copy running with a sanitized copy of the data.
If the code in the repository does not match what is running in production, you have found the most important risk. It happens more often than you would think.
Once it builds, set up a simple CI pipeline that builds it on every push. That turns "it built on my machine once" into a repeatable fact. See a CI/CD pipeline for a small team.
Day 4 to 7: Map the system
Draw a simple map, even on paper:
- Which services exist, what each does and how they talk to each other.
- Where data lives: databases, file storage, caches.
- External integrations and what depends on them.
- Scheduled jobs and background workers.
- How deployments currently happen.
Then trace the two or three most important business flows through the code end to end, for example "customer places a booking" or "technician completes a job". This tells you more about the quality of the system than any amount of browsing.
Week 2: Assess the risks
With the system mapped, look for the things that can hurt the business soonest:
Data safety. Are there backups? Off-site? Has anyone ever restored one? If not, fix this first. See Postgres backups that actually restore.
Security. Exposed database ports, default passwords, outdated packages with known vulnerabilities, secrets in the repository, missing permission checks on API endpoints, unpatched servers. See hardening a new Linux server.
Platform deadlines. Mobile apps targeting old SDKs may be blocked from updating by the stores. Framework or runtime versions near end of support. Certificates and domains close to expiry.
Single points of failure. One server with no monitoring, one person who knows the deploy steps, one integration with no fallback.
Code health. Tests, structure, consistency, how hard it is to change the core flows. This matters, but it ranks below the items above, because bad code that runs safely is less urgent than good code with no backups.
The report
At the end of the two weeks, the business should get a short, plain-language report:
- What the system is, with the map.
- What has been secured already.
- The top risks, ranked, with what it takes to address each.
- The state of the code, honestly.
- A recommendation: stabilize and improve, or plan a rebuild.
This is essentially a technical due diligence of the system, adapted for a business rather than an investor. The checklist in what a technical audit should cover applies directly.
Fix or rebuild?
Rewrites are tempting and frequently fail. The old system contains years of business rules, edge cases and fixes that nobody documented, and a rebuild has to rediscover all of them while the business waits.
I recommend improving the existing system when:
- It works for users and the core data model is reasonable.
- The problems are concentrated in some areas, not everywhere.
- The stack is still supported or can be upgraded step by step.
A rebuild becomes reasonable when:
- The stack is unsupported and cannot be upgraded incrementally.
- The data model is fundamentally wrong for how the business works now.
- Every change breaks something unrelated and there is no realistic way to add safety.
- The product's direction has changed so much that little of the old system applies.
Even then, an incremental replacement, rebuilding one part at a time behind the same API or database, is usually safer than a big-bang rewrite.
Keeping the lights on during the takeover
Users do not stop using the product while you learn it. During the first weeks I avoid feature work, but I do make small, safe changes: adding monitoring and error tracking so problems are visible, fixing urgent bugs with minimal edits, and documenting every deployment I make. Each small change is also a test of the process. If a one-line fix takes a day to ship safely, that tells you what to improve first. See monitoring and alerts for a small product for a minimal setup that works well here.
What the business can do to help
- Gather every account, invoice and email related to the system.
- Ask the former developer, politely, for a handover call, even a short one.
- List the known problems and the changes you need, ranked by importance.
- Be patient for two weeks. The time spent understanding the system pays back quickly.
Preventing this next time
The best protection is set up at the start of any project: accounts in the company's name, code in a company repository, a written runbook, automated deployments and documented environments. See questions to ask before hiring a developer.
If you have inherited an app or platform and need someone to take it over, see my work and get in touch.