Taking over an existing app or web product starts with a review that costs $900–1,500 and takes 3–5 days. Fixing only the urgent problems costs $3,000–7,500. Stabilizing a live product costs $10,000–24,000, and rewriting the weak parts and finishing it $22,000–48,000. My last three takeovers cost $16,000–25,000 each.
Takeovers happen when a developer leaves, an agency leaves a product half-built, or an app built with AI tools breaks under real users. This post is about the bigger jobs: products with real code, users, or a half-finished feature list. If your app was built with Lovable, Bolt, or Replit and needs fixing rather than finishing, the smaller prices are in what it costs to fix a vibe-coded app. The price depends on how much of what you have can be kept, and nobody knows that until they've read the code. That's why every product takeover I do starts with a paid review. Below are the prices by stage, what the review should tell you, three real takeovers, the costs most quotes leave out, and a checklist that makes the whole thing cheaper.
App takeover cost by stage
Freelance prices in US dollars, for a product that already exists in some form: live with users, half-built, or a demo that breaks.
| Stage | Cost | Timeline | What you get |
|---|---|---|---|
| Review and rescue plan | $900–1,500 | 3–5 days | A written report: what to keep, fix, and rewrite, with a fixed price for the next step. |
| Fix only the urgent problems | $3,000–7,500 | Set in the review | Security holes, broken logins, or payment bugs fixed, and the app deployed properly. No new features. |
| Stabilize and fix | $10,000–24,000 | 4–10 weeks | Crashes, security holes, and slow parts fixed while the product stays live. |
| Rewrite the weak parts and finish | $22,000–48,000 | 8–16 weeks | Keep what's solid, rewrite what won't scale, and build the missing features. |
| Type | Typical range | Real projects |
|---|---|---|
| Review and rescue plan | $900–1,500 | — |
| Fix only the urgent problems | $3,000–7,500 | — |
| Stabilize and fix | $10,000–24,000 | — |
| Rewrite the weak parts and finish | $22,000–48,000 | — |
| My last three takeovers | — | Social challenge app: $16,000; AI chatbot SaaS: $20,000; Local news app: $25,000 |
Most takeovers don't go through every row. A live product with paying users usually needs the review and then stabilizing, so it stops breaking before anything new is built. A half-built product with no users yet often skips straight from the review to finishing it, because there's nothing live to protect. Some apps only need the urgent fixes and a proper deploy, which is the second row and my Production Sprint. The review fee comes off the next step if you continue with me.
For comparison, in my experience rescue agencies quote noticeably more for the same work. The difference is mostly team size and overhead, which is the same trade-off as hiring a freelancer or an agency for anything else.
What a code review should tell you
A review is the cheapest part of a takeover and the one that saves the most money, because it turns "it depends" into a fixed price. You're paying someone to read everything before they promise anything. A useful review report answers these questions, in plain English:
- What do you actually own? Every account the product runs on, and which ones are in your name
- How is it built?The main technologies, and whether they're common enough to hire for later
- What's broken or risky? Security holes, data that could be lost, and anything that handles money
- What's worth keeping? Which parts are solid, which need fixing, and which should be rewritten, with reasons
- What's missing?Features that were promised but never finished, and what they'll take
- What happens next? A fixed price and timeline for the next stage, in priority order
If a report only lists code problems without telling you what to do and what it costs, it isn't finished. And you should own the report outright, so you can take it to anyone. On The Chat Company, reading the code first is what showed that only about 20% of the AI-generated demo was worth keeping, which set the plan and the price for everything after it.
Three real app takeovers and what they cost
Ranges only go so far. These are my last three takeovers, with the starting point, the price, and what happened after.
| Project | Starting point | Cost and time | Result |
|---|---|---|---|
| Social challenge app | Half-built by an agency | $16,000, 8 weeks | Live, with 10,000 users and $40K staked |
| AI chatbot SaaS | Buggy AI-generated demo | $20,000, 9 weeks | 30+ businesses, 100K+ messages a day |
| Local news app | Half-built by an agency | $25,000, 12 weeks | 50K downloads, 20K monthly readers |
Social challenge app: $16,000, with real money involved
An agency had left the social challenge app half-built on a foundation that wouldn't scale. Users stake money on challenges to X accounts, so wallets, crowd contributions, and payouts had to be right. I kept what worked, rewrote the rest, and finished it in eight weeks. It now has 10,000 users, 3,000+ challenges, and $40K staked.
AI chatbot SaaS: $20,000, 80% rewritten
The Chat Company started as a demo generated with AI tools. It showed the idea but couldn't serve real businesses. I kept about 20%, rewrote the other 80%, and built the full product in nine weeks: the website crawler, the AI answer engine, a widget businesses install with one line of code, and analytics. It now serves 30+ businesses.
Local news app: $25,000 for two app stores
The local news app was also left half-built by an agency. It cost the most of the three because the finished product was bigger: an iOS and Android app, a backend, an editor admin, location-based news, push alerts, and releases to both stores. It shipped in 12 weeks and has 50K downloads.
What makes an app takeover cost more
Two apps with the same features can cost very different amounts to take over. These are the things that move the price, roughly in order of how much.
How much of the code is usable
The single biggest factor. Solid code gets fixed and extended. Fragile code gets replaced, which costs more. AI-generated apps often look finished but hide shaky foundations, so more of them tends to be rewritten. Products left by an agency or another developer usually have more to keep, but come with less explanation.
How much is left to build
A product that works but is shaky costs less than one where half the features were never finished. Be honest with yourself here: if the missing half is the part customers pay for, you're closer to building a product than fixing one.
Money, personal data, and live users
Products that handle payments or personal data need extra care and testing, because a mistake there is expensive. Fixing a product with live users also takes longer than fixing one nobody uses yet, because every change has to go out without breaking what they rely on.
Whether you have full access
Missing logins for the code, hosting, database, or app stores add days or weeks before real work can start.
Takeover vs rewrite: which costs less
A full rewrite sounds clean, but it means paying again for everything that already works, while your users wait. A takeover keeps the good parts and replaces the bad ones step by step, with the product live the whole time. It's usually cheaper and faster, unless almost nothing in the codebase is usable, which is exactly what the review will tell you. A rewrite also resets the clock on bugs: code that has run with real users for a year has had its problems found and fixed, and new code hasn't.
Even The Chat Company, where 80% was rewritten, was still a takeover rather than a restart: the 20% that stayed didn't have to be designed, built, or tested again, and the founder didn't lose the ideas already worked out in the demo. The full decision is in take it over or rewrite it, and if your app was built with tools like Lovable, Bolt, or Cursor, see hiring a developer for an AI-generated app.
Red flags in an app takeover quote
When your product is already in trouble, it's easy to accept the first quote that sounds confident. These are the signs to slow down:
Good questions to ask anyone quoting a takeover: What will you check first? Will I get a written report I can keep? Which parts do you expect to keep, and why? How will you release changes without breaking things for current users? Who owns every account at the end? A developer who has done takeovers before will answer these without hesitating, and the answers will tell you more than the price. Ask every developer the same questions, in writing, so you can compare their answers side by side.
A handover checklist to lower the cost
Every item you can hand over on day one is time the new developer doesn't spend digging, and time you don't pay for. Collect as much of this as you can before the review starts:
- Access to the code repository, such as GitHub, GitLab, or Bitbucket
- Hosting and server logins, and the domain registrar
- Database access, and the latest backup
- Every service the app uses: payments, email, login, AI, analytics
- Apple and Google developer accounts, for mobile apps
- Any documents the previous team left: specs, designs, notes, tickets
- A list of what works, what's broken, and what was never finished
- The three things that matter most for the next launch
Don't worry if some of it is missing. Finding out what's missing is part of the review. But the more of this list you have, the shorter and cheaper the review, and the sooner real work starts.
To get a first estimate, tell me what you have: how it was built, what's going wrong, and whether it has users. I'll tell you what the review would cost and what's likely worth keeping.
