On 13 August 2026 we were the team leaving. Trainr, the two-sided fitness marketplace we had built for Watermelon Inc in Dubai, passed to its incoming developer that day, and a handover is only as good as the list behind it.
What we gave them: the store and service accounts, the signing material, deploy and rollback runbooks, environment templates for all four codebases, a full export of the media bucket, and a written record of every system's state, the open items, and whose court each one sat in.
Being on that side of a takeover is clarifying. You find out how much of an app lives in people's heads and in accounts nobody remembers opening. So this plan for the first 30 days of taking over an app is written from both directions: what we'd want if we were inheriting your app, and what we made sure to leave behind when we were the ones going.
Before day one: write the access list
Before anyone tells the old team the relationship is ending, sit down and check, personally, that you can get into each of these:
- the Google Play Console and App Store Connect, as account owner, not an invited user;
- the Android upload key and keystore details, and the Apple certificates and profiles;
- every code repository, including the backend, the admin console and any scripts (Trainr had four);
- the server or cloud account, and the database;
- the domain registrar itself, not just the DNS records;
- the payment provider, email sender, maps, push notifications and error monitoring.
Every "no" on that list is a conversation to have while everyone is still friendly. It gets much harder once the last invoice is in dispute. Our agency handover checklist has the full inventory, written from the outgoing team's side so you can send it to them as a request.
Week 1: own everything, change nothing
The first week is administrative and it should be. Move each account into the owner's name. Then rotate every secret, because anyone who had the old keys still has them. Environment templates help here: a list of every setting each part of the system needs, without the secret values, which travel separately and get replaced. See secrets management if the term is new.
Two things we did for Trainr that are worth copying.
First, error monitoring moved into Trainr's own organisation. Then we checked the move had really happened in the shipped app, not just in a settings screen: we pulled the JavaScript bundle out of the built app and searched it. The new reporting address appeared once. The old one appeared nowhere. It is the surest way to know crashes from real phones now reach the new owner. A glossary note on error monitoring explains why this matters in the first weeks especially.
Second, the media. Uploaded photos and files are easy to forget because they don't live in the code or the database. We handed over a full export of the bucket.
No feature work this week. Security fixes are the only exception.
Week 2: read the code before touching it
Unfamiliar code always looks worse than it is. That is the single most expensive fact about takeovers, because it is why new teams propose rewrites in week one. A rewrite started that early throws away working behaviour that nobody wrote down.
So week two is reading, with read-only access, so nothing changes while you look. When we run this as a code audit, it has a fixed shape:
| Day | What happens |
|---|---|
| 1 | Read-only access, and a short call about what worries you |
| 2 and 3 | The architecture, data model, security, dependencies and tests |
| 4 | Findings written up, ranked by severity, each with the file and line it comes from |
| 5 | A walkthrough, a verdict per area, and a fixed-price quote for what comes next |
The file-and-line rule is the part that matters. "The payment code is bad" starts an argument. A finding that names the file, the line and what can go wrong starts a fix, and anyone can check it.
A standard audit of one app or one backend, up to about 50,000 lines, costs ₹90,000 ($950). An app and its backend together, about 50,000 to 150,000 lines, is ₹1,60,000 ($1,680) and takes seven to eight working days. The fee is credited to the fix or takeover work if it starts within 60 days, and the report is yours to take to any team. We audit JavaScript, TypeScript and Flutter (Dart) apps.
Expect at least one problem that looks like something else. Trainr's iPhone uploads had been failing since 25 May with a signing error that read like a permissions problem. It wasn't one. Apple's records showed the app had always been fit.trainr.mobile, and a brand rename had changed the iOS identifier to match the Android one. We reverted it, added six privacy purpose strings Apple required, and build 22 reached TestFlight. None of that was visible from the code. It took access to the store account to see, which is one more reason week one comes first.
Week 3: ship something boring
The first release from the new team should change as little as possible. A version bump, a dependency patch, one small fix. Its real job is to prove the release path works in new hands: the build, the app signing, the store submission, the server deploy and the rollback.
If any of that is wrong, you want it to fail on something harmless rather than on the urgent fix a customer is waiting for. Ship it to a small share of users first and watch errors and store reviews for a few days. Our QA and testing page lists the release checks we run, and deployment and hosting covers the server side.
Small release-build details turn up here too. On Trainr we stripped 540 console calls from release builds while keeping errors and warnings for crash reports, and checked on the built Android bundle that only the two processor architectures we meant to ship were inside it. Nobody would call either a feature. Both are the kind of thing a new team should know is already done.
Also in week three: find the next store deadline. Google and Apple set requirements on fixed dates, and a takeover that lands a month before one has to put that update first, whatever else the audit says. Gaps in data-safety answers and account deletion are the usual blockers; our guide to Google Play data safety and account deletion covers them.
Week 4: a verdict for each area, then a price
By now you know enough to decide, but decide per area, never for the whole app:
| Verdict | When it fits |
|---|---|
| Fix | The structure is sound. Specific bugs or gaps need closing. |
| Refactor | It works, but changing it is slow or risky. Restructure it and keep the behaviour. |
| Rebuild | It can't be made safe or fast enough, and nothing else depends on its quirks. |
Most apps we look at are mostly "fix", with one or two "refactor" areas and rarely a true "rebuild". The rebuild is the most expensive verdict and the one people reach for first. When someone proposes it, ask for the evidence: is the data model itself wrong, so every feature fights it? Is a core library abandoned on the path that handles money or sign-in? Or is the code just written in a style the new team dislikes? Style is not technical debt that blocks the business.
One distinction saves a lot of budget: separate "broken" from "never built". An app can be missing push notifications, or tax handling, or an admin report, without anything being wrong with it. Those are features to price, not defects to blame on anyone. When Trainr asked for UAE VAT, for instance, that was a new feature, not a defect, and we listed the decisions the business had to make before writing any of it.
The month should end with five things:
- every account and key in the owner's name, with secrets rotated;
- the app building and releasing from the new team's machines;
- a ranked, evidenced list of what is wrong, with a verdict per area;
- the urgent items closed, security first, then anything blocking a release;
- a priced plan for the rest.
Not on the list: a half-started rewrite.
What a good outgoing team leaves behind
Even when a relationship has soured, the old team knows things that are written down nowhere. It is worth paying for a short handover window rather than a clean break: a walkthrough of how a release reaches each store, the known issues and half-finished work in their own words, and the reasons behind decisions that look odd. There is often a good one.
When we were the outgoing team, the most useful thing we wrote was the plainest: every system, its state, what was still open, and who owned the next move on each item. It isn't clever. It saves the incoming team weeks of guessing. It is reasonable to ask any team you're leaving for the same, and our glossary entry on a handover describes what a complete one contains.
Who should do it
A takeover rewards skills that are hard to find in one person: reading other people's code carefully, owning releases across two stores and a server, and writing things down. A strong freelancer can manage a small app. For two platforms, a backend and an admin console, a small team usually covers more ground with less risk; our comparison of freelancers, agencies and studios goes through the trade-offs.
Our app rescue and takeover page describes how we take over React Native, Node.js, Next.js and MongoDB stacks, and the maintenance and takeover topic collects what comes after the first month.
Whoever you pick, ask one question in the first meeting: how would you spend the first week? If the answer starts with a rewrite, keep looking.