How to take over an app from another vendor
For founders · Updated
Filip Papranecfounder of Digitaliko
You take over an app from another vendor in three steps. First you secure the code, access and data while the old vendor still answers. Then someone independent looks into the code. Only then do you decide whether to continue, harden, or start over.
Before anyone looks into the code, the price of a takeover is always just a guess. Below we describe what to ask for, what we look at and which verdicts are possible. Since 2023 we have delivered 15+ production projects.
What should you ask the old vendor for while they still answer?
The relationship rarely ends on good terms. The sooner you ask for what you need, the less it will hurt. Ask in writing, by email. Tick what you already have in hand:
Who owns the rights to the code is covered in Who owns the source code of custom software?. If the vendor holds your data back, see Vendor won't release your data? What to do.
How do you find out what state the app is in?
A demo on screen proves nothing. What counts is what is in the repository and whether it runs without the original author. When we take over an app, we look at five things:
- Can the app be run from scratch? Following the instructions, on a clean machine. If not, the first job is clear.
- Does the green tick in CI mean anything? Often the pipeline runs but never stops a merge. And without tests it has nothing to fail on.
- Are passwords and keys outside the code? They have no business in the repository. If they are there, they need to be rotated.
- Is access control the same everywhere? A common mistake: one part has proper login, the part next to it hands data to anyone.
- Will anyone notice an outage? Monitoring and alerts, not a customer who calls.
When we audited one vibe-coded app, we found a public repository, a secret key right in the code and a CI that had never stopped anything. There were no tests, so nothing could fail. The founder made the repository private while we were still on the call.
We learned the last point from our own mistake. On a project for a client with an online marketplace, a crawler stopped running in December 2025. We noticed it late, only from a chart. Meanwhile traffic dropped sharply. That is why on a takeover we look at monitoring right at the start.
- pageviews a month by the time we noticed the crawler had stopped
- 250K → 66K
All five points and the other checks are in one place. Download the 25 checks before launch (PDF).
Continue, harden, or start over?
After looking into the code you get one of three verdicts. Each means different work and a different price.
| Verdict | When | What it means |
|---|---|---|
| Continue | The foundation holds, tests verify something, deployment can be repeated | The new vendor carries on developing further features |
| Harden | The app works, but security, tests or monitoring are missing | Fix those first, then further features |
| Start over | Fixes would take longer than a new version | The prototype stays as the brief, the code is written anew |
In the cases we have seen, it was mostly not a rewrite. We did not propose one in that audit either. We proposed rules for working with AI and separate environments, and the founder built a clean new production setup from the existing code. Usually it means a few security fixes, getting deployment working, and then normal work. A vendor who tells you to "throw it all away" without looking into the code is selling a rewrite.
How much does taking over an app cost?
Nobody can honestly say before looking into the code. Not even us. The price depends on the verdict, and the verdict depends on the code.
That is why we don't start with a quote. We look into the repository and then tell you which of the three verdicts applies and what it means for the first month. If someone sends you a figure without opening the repository, treat it as a blind guess.
01
Send access to the repository
And if you have it, a guide to running the app.
02
We look into the code
Runs from scratch, CI, passwords, access and monitoring.
03
You get a verdict
Continue, harden, or start over.
04
We write down month one
A list: what will be done and how you can check it.
We handle a takeover and the development after it the same way as MVP development for founders: a monthly subscription you can cancel in any month.
What if you vibe-coded the app yourself?
It was not wasted. It is the best brief you can give a vendor. A prototype shows how the product should work better than any specification. After the audit we told that founder plainly where he was strong and where he was weak.
Your product and logic are strong. Deployment is the weak part, and it will kill you once you stop doing it all yourself.
You know how your company works. Our job is to get that out of your head and into software that lasts for years. And you don't have to stop experimenting. We set up the repository so that what you try fits into the rest of the system.
What a prototype is missing for live operation is covered in From vibe-coded prototype to production. If an agency failed to deliver your app, start with The agency didn't deliver the app. What now?.
When we don't recommend it
- The old vendor answers and you are happy with them. Do not switch. Just ask for the repository and accounts in your company's name.
- The app is a ready-made product or SaaS they only customised. The code is not yours and cannot be taken over. Focus on exporting your data.
- Nobody uses the app any more and you have no plans for it. Do not take it over. Back up the data and switch it off.
- You want a takeover price before anyone looks at the code. You will not get one from us. Any such number is a blind guess.
Got an app from another vendor?
Send us access to the repository. We get back to you within two business days, and together we pick what to fix first.
If you'd rather talk first, book a 15-minute meeting with Filip.
What do you miss most in the app your old vendor left you?
In short
- First secure the repository with its history, access, the domain and data while the old vendor still answers.
- The repository tells you the app's state, not a demo: runs from scratch, CI, passwords, access and monitoring.
- After a look into the code you get one of three verdicts: continue, harden, or start over.
- A takeover price without opening the repository is a blind guess.
Frequently asked questions
How do you take over an app from another vendor?
First ask the old vendor for the repository with its full history, access to servers and the domain, and a data export. Then let the new vendor look into the code. Only then decide whether to continue, harden, or start over.
How much does taking over an app cost?
Nobody can honestly say before looking into the code. The price depends on the verdict: continuing is cheaper than hardening, and hardening is cheaper than starting over. Any figure given without opening the repository is just a guess.
Does the old vendor have to hand over the source code?
It depends on the contract. For software made to order, the client usually exercises the economic rights, but you also need the code physically in your hands. If the vendor refuses to release it, start with the contract and a written request.
Can you keep developing an app someone else wrote?
Usually yes. More often than a rewrite, what is needed is hardening security, deployment and monitoring. Starting over only pays off when it is faster than fixing.
What if I vibe-coded the app myself?
It was not wasted. A working prototype is the best brief you can give. The new vendor sees from it how the product should work, and decides what stays in the code.
Ask AI about this article
The AI also draws on our other articles and experience from real projects.
ChatGPTClaudePerplexity
