Taking over an app? First find out why fixes don't stick.
Every fix seemed to open a new problem somewhere else. Here's what we check in the first two weeks after taking over an app someone else built.
Late in 2025, a travel app called Neebu came to us with a familiar story. It had reached the app stores far later than planned. Every fix from the previous team seemed to open a new problem somewhere else. The client didn't want a rewrite. They wanted someone to take responsibility for all of it.
We've done a few of these handovers. The first two weeks always follow the same plan.
1. Get every key, not only the code.
The code is the least of it. Before we touch a line, we collect access to the app store accounts, servers, domain, push-notification keys, Android and iOS signing keys, and every outside service the app leans on. Miss one, and a finished fix can't go out. You find that out at the worst possible moment.
This step is dull. It's also where most handovers quietly fail.
2. Build it once, on a clean computer.
Next, we build the app from scratch on a computer that has never seen it. If that fails, every later fix is guesswork resting on someone's laptop.
The tools it's built with are usually a couple of years behind. We update them now, quietly, before any visible change, so the client never wonders whether a bug came from a fix or the upgrade.
3. Find the bugs that share a cause.
Clients arrive with a list. Neebu's was long and numbered. Rather than start at the top, we read the whole thing first.
A bug that keeps coming back somewhere else almost always has one of three causes:
- The same information is kept in two places, and only one gets updated.
- The app forgets something it should remember.
- The app and the server disagree about a rule.
Ten bugs can be one problem wearing ten costumes.
4. Fix it where it breaks.
On Neebu, a notification that opened the wrong page wasn't an app bug at all. The server was sending a field under a misspelled name. Correcting the name fixed every notification at once. Patching the app would have fixed one.
That's how a bug list shrinks instead of moving around.
5. Release small updates often.
Big, late releases are how trust gets lost. So we send small batches to both stores on a rhythm the client can plan around. Their own list becomes the release notes. Predictable beats fast.
Done this way, a handover changes what the product feels like to own. Neebu ships on a schedule now, and its open issues get fewer instead of moving around. What started as a takeover is now a standing retainer.
If you're sitting on an app you no longer trust, tell us about it. The first two weeks are the same, whoever built it.
