A new agency is taking over your app: how it works
Taking over an existing app starts with a technical audit showing the state of the code, before anything gets built further. At the same time, all assets get secured: source code, accounts, certificates, and backend. Continued development usually pays off over rewriting from scratch, but if the code is in very poor shape, a rewrite can be cheaper long term.
You have an app that works but a vendor you want to leave, or a project that’s stalled. The good news is you rarely need to start over. A takeover is a craft with clear steps, and with the right preparation, a new partner can build on what already exists.
The first step: a technical audit
Before anyone promises anything about timeline or price, the new partner needs to understand what they’re taking on. That happens through a technical audit, a review of the code, the architecture, and the services the app relies on.
The audit answers questions like:
- How is the app built, and with what technology?
- Is the code structured and readable, or patched together and hard to follow?
- What third-party services and dependencies exist, and are they current?
- What’s the biggest risk if we keep building on it as-is?
The result is a snapshot of the current state: what can be reused, what should be fixed, and a rough estimate of what continuing costs. The point is that you make decisions on facts instead of gut feeling. A serious partner always wants to do this review before taking on a handover.
Secure the assets: code, accounts, certificates, backend
In parallel with the audit, you need to gain control over the app’s assets. This is the part that’s most often underestimated, and it can become genuinely painful if it’s missed.
| Asset | Why it's critical |
|---|---|
| Source code | Without the full code, the app can't be developed further at all |
| Apple and Google accounts | Ownership determines who can update and publish the app |
| Signing certificates and keys | Required to release updates as the same app |
| Backend and databases | This is where the users' data and the app's logic live |
| Third-party accounts | Payment, maps, notifications, and more otherwise stop working |
The crucial thing is to secure these before ending the old relationship. As long as you own the code and accounts, a new partner can pick up, even if the previous vendor doesn’t help. If you’ve let go of a certificate or an account, a simple update can suddenly turn into a major operation.
When continued development beats a rebuild, and vice versa
The basic rule: don’t throw away working code. Rewriting an app from scratch is expensive and risky, and most of the old work can often be built on. In most cases, continued development is the clearly cheaper choice.
But there are exceptions. A rewrite can be justified when:
- The technology is so old it no longer gets updates.
- The code lacks structure, so every small change takes disproportionately long.
- The app is changing so much that little of the old version would survive anyway.
A concrete example: an app built on a framework that’s no longer maintained, where every new feature requires workarounds. There, a rewrite might cost more up front but become cheaper over a few years, since continued development gets more expensive with every change. The audit is what determines which situation you’re in.
What a successful takeover looks like in practice
The order that tends to work: you secure the assets, a new partner does an audit, you agree on a plan for the first improvements, and then the new partner gradually takes over responsibility. Starting with a contained first delivery is a good way to build trust before entering a larger commitment.
Good practice is to let the new partner fully own one contained part before you scale up. That lets both sides see how the collaboration works in practice, and you build trust step by step instead of shifting all responsibility over at once.
Avoid getting stuck in the old relationship
Many hesitate to switch for fear of getting stuck, that the old vendor holds something that makes you dependent. That’s exactly why ownership is so central. If the code, accounts, and certificates are yours, a new partner can pick up even if the previous vendor doesn’t lift a finger.
If you’ve already ended up in that situation, the advice is to first secure what you can access, and map out what might be missing. Even incomplete access can often be worked with, and an audit shows how big the gap is and what it would take to close it.
At Weapp, we’ve taken over apps from other vendors and built on them, and the common thread across the smooth handovers is that the client had control over their assets. Want to know whether your app can be built on? We’re happy to help with a technical review, get in touch with a short description.
Frequently asked questions
Can a new agency take over an app someone else built?
Yes, it's common. The condition is that the new partner gets access to the source code, accounts, and certificates. The first step is a technical audit where they assess the state of the code and document how the app is built. Without access to the code, the takeover becomes difficult, and sometimes impossible.
What is a technical audit, and what does it deliver?
It's a review where developers go through the code, architecture, and dependencies to assess condition and risk. The result is a picture of what can be built on, what needs fixing, and roughly what it costs. It lets you make decisions on facts instead of guesses.
Which assets do I need to secure when switching providers?
The complete source code, ownership of the Apple and Google accounts, signing certificates and keys, and access to the backend, databases, and third-party services. Missing any of this can make the app impossible to update. Secure the assets before ending the relationship with the old vendor.
Is it cheaper to rewrite the app from scratch?
Usually not. Throwing away working code and starting over is rarely worthwhile if the foundation is reasonable. The exception is code in very poor shape, with outdated technology or no structure, where every change becomes expensive. There, a rewrite can be cheaper over time despite the higher starting cost.
What happens if the old vendor doesn't cooperate?
It makes things harder but doesn't have to stop the takeover, provided you own the code and accounts. That's why it's important for ownership to be clear already in the original agreement. If you have access to the code and accounts, a new partner can pick up even without the old vendor's help.