We get a lot of calls that start the same way. “Our developer has moved on, the app still runs, and we need someone to take it over.” Sometimes it’s an agency that closed. Sometimes a freelancer took a full-time job. Either way, the business still depends on the product and there’s a list of features everyone wanted last month.
The instinct is to start on that list straight away. We’ve learned not to. A team that doesn’t understand a system yet will be slow, will break things it didn’t know were connected, and will burn trust in the first few weeks. A short, boring handover prevents most of that. Here’s the checklist we use.
1. Get access to everything
Before we read a line of code, we check who owns the accounts. It should be the business, not a person.
- The code repositories, with full history
- Hosting, cloud and database accounts
- The domain registrar and DNS
- Apple and Google developer accounts
- Payment, email, analytics, maps and push notification services
- Passwords, API keys and environment settings for every environment
Missing access is the biggest risk in any handover, and the cheapest one to fix while the previous team still answers emails. Once they stop replying, recovering an app store account or a domain can take weeks.
2. Make it run
Can a new engineer clone the repository and get the app running on their machine? Surprisingly often, the answer is no. There’s a missing config file, an old database dump someone had locally, or a step that only lived in one person’s head.
We write down every step and every workaround as we go. That note becomes the setup guide, and it saves days for anyone who joins after us.
Then we look at how code actually gets to production. Is there an automated pipeline, or does a release depend on someone’s laptop? You need to know this before you change anything, because the first release is usually where surprises show up.
3. Map the system
Nobody needs a 40-page document here. A diagram and a page of notes is enough, as long as it covers:
- The main pieces (web app, mobile apps, APIs, background jobs, admin tools) and how they talk to each other
- Where the data lives, and which tables matter most
- Which outside services the main user journey depends on
- Scheduled jobs, and anything else that runs without a user clicking something
The point is a shared picture of the system, so the whole team is talking about the same thing.
4. Find the fragile parts
Every inherited codebase has areas that break easily. We go looking for them on purpose. Error logs show what fails most often. Support tickets show where real users get stuck. Then we check for code that handles money, bookings or personal data with no tests around it, and for outdated libraries with known security issues.
We rank what we find by business risk. Messy code that never breaks can wait. A clean-looking checkout that fails every Friday can’t.
5. Stabilize before you build
The first few weeks go into the highest-risk fixes: security updates, failing background jobs, backups that were never tested, that one bug everyone has learned to live with. We add monitoring so problems show up on a dashboard before a customer reports them.
This is the phase where trust gets built. The business sees fewer incidents, and our team learns the system by working on real problems inside it, which beats reading code in the abstract.
6. Then plan the roadmap
Only when the app is stable and understood do we start planning new features or bigger changes. By then estimates are realistic, and it’s much clearer what can be improved step by step and what, if anything, really needs rebuilding.
A good handover takes a few weeks, not months. It feels slow at the start, but it’s the quickest way we know to start shipping new work without nervous releases.
