How long does a takeover take?

The code review takes 1–2 weeks. Stabilizing a live product usually takes 4–10 weeks, and finishing a half-built one takes 8–16 weeks. My last three takeovers took between 8 and 12 weeks from taking over to launch. The review gives you a firm timeline for your product before the main work starts.

Will my users notice during a takeover?

They should notice things getting better, not breaking. Fixes are released in small steps, tested before they go live, and the product stays up throughout. If a change affects how users work, like a new login flow, tell them in advance. Most users only notice fewer bugs and faster pages.

Do you have to keep the same technology as before?

Usually, yes, at least at first. Keeping the same stack means fixes and features can ship quickly without a rebuild. Parts can move to better technology later, one piece at a time, if there's a real reason, such as a tool that's no longer maintained or a part that can't handle growing traffic.

Should I ask the old developer to help with the handover?

If they're willing, yes. Even an hour's call explaining how the product is deployed, where things live, and what's unfinished can save days. Pay for their time if needed; it's usually the cheapest hour of the whole takeover. If they won't help, a code review can still work out everything, it just takes a little longer.

Should you rewrite a live product, or take it over?

Take over and fix a live product when users already rely on it and parts of the code are solid. Rewrite it from scratch only when a code review shows almost nothing is usable, secure, or able to grow. In most cases a takeover is cheaper and faster, because you keep what works and replace the rest step by step while the product stays live.

The usual situation: the developer left, an agency left the product half-built, or an app built with AI tools breaks under real users. The first instinct is often to start again. Here's how I decide, from the product takeoversI've done.

Take over or rewrite: the quick test

Take it over when

There's something worth keeping

The product works for users, even if it's messy
Parts of the code are solid and can be kept
You can't afford months without shipping
The problems are in specific areas, not everywhere

Rewrite when

There's almost nothing to keep

Almost nothing in the code is usable or secure
The technology is abandoned or can't scale at all
The product is changing so much the old code won't fit
A review confirms fixing would cost more than rebuilding

The cut

Don't decide before someone reads the code. A 1–2 week review tells you which side you're on, and it costs far less than choosing wrong.

What to do in the first week after your developer leaves

Before deciding anything about the code, protect what you have. These steps don't need a developer, and they make every later option cheaper:

If the code only lives in the old developer's account, ask for it in writing and check your contract for who owns it. Nobody can help you fix or finish a product they can't get into.

Why full rewrites usually cost more than expected

A rewrite means paying again for everything that already works: logins, payments, emails, admin screens, and all the small fixes users no longer notice. Meanwhile the old product still needs attention, and users wait months for anything new.

Rewrites also tend to grow. Once everything is being rebuilt, new features get added, the date slips, and the budget follows. Fixing and finishing the existing product keeps the scope small and visible. The best-known warning is Netscape. It decided to rewrite its browser from scratch and went nearly three years between major releases, while competitors kept shipping. Software developer Joel Spolsky called rewriting from scratch the single worst strategic mistake a software company can make. Your product is smaller, but the risk has the same shape: months of paying for work users can't see.

How to tell if the code is worth keeping, without reading it

You don't need to be technical to gather good evidence before a review. Look at what the product does, not what it looks like:

Do users complete their main task?If the core flow works most days, there's something solid underneath.
Where do the bugs cluster? Problems in one or two areas point to a fix. Problems everywhere point to a deeper issue.
Can someone release a change safely?If nobody knows how to deploy it, that's the first thing to fix.
Is any of it written down? Notes, tests, or a setup guide make keeping the code much cheaper.

Bring these answers to the code review. They tell the reviewer where to look first, and they help you judge whether the review's recommendation matches what you see every day.

How a product takeover works

1. Get access to everything

Code, hosting, database, domain, app stores, and any paid services, all moved into accounts you own.

2. Review the code

What's solid, what's risky, and what's missing, in a written report with a price and timeline for the next step.

3. Fix the urgent problems

Crashes, security holes, data risks, and anything losing you customers come first, before new features.

4. Replace weak parts step by step

Fragile code is rewritten one area at a time, tested, and released, so users always have a working product.

5. Finish and keep building

The missing features get built on the improved foundation, and the product gets documentation so any developer can work on it later.

How piece-by-piece replacement works

When parts of a product do need rebuilding, they don't have to be rebuilt all at once. Software architect Martin Fowler calls the approach a strangler fig, after a vine that slowly grows around a tree: new parts are built next to the old ones, and traffic moves to each new part only once it works.

In practice, that might mean rebuilding checkout first while the rest of the product stays as it is, then the dashboard, then the admin. Users see steady improvements instead of a long wait, and if a new part has a problem, the old one is still there to fall back on. It's how 80% of The Chat Company could be rewritten without starting the product over.

Real product takeovers

The Chat Company: a buggy AI-generated demo. I kept about 20%, rewrote 80%, and built the rest in 9 weeks. It now handles 100K+ messages a day.
A social challenge app: left half-built by an agency. Launched 8 weeks after I took over; it now has 10,000 users.
A local news app: also left half-built by an agency. Shipped to both app stores in 12 weeks, with 50K downloads since.

None of the three needed a rewrite from scratch. In each case, the review found something worth building on: working backend code in the chatbot, and core flows in the two agency builds. Keeping those saved weeks of work and let each product launch sooner. Costs for each are in how much a takeover costs.

When a rewrite really is the right call

Rewrites aren't always wrong. They make sense when a review finds one of these, with evidence rather than opinion:

Security that can't be patched. Customer data or payments are exposed in ways built into the design.
Abandoned technology.The tools it's built on no longer get updates, and few developers know them.
A different product. The business has changed so much that the old code models the wrong thing.

Even then, a rewrite can usually happen in pieces, reusing what's sound. The Chat Company is the example: 80% of the code was replaced, but the 20% that worked stayed, and the founder never had to start the product over.

Warning signs you're being sold a rewrite

A full rewrite quoted without anyone reading the code
"The old code is terrible" with no specifics
A new technology stack chosen before the problems are clear
No plan for keeping the current product running meanwhile

A trustworthy recommendation looks different. It names the specific parts to keep and to replace, with a reason for each. It gives a price and timeline per stage, not one big number. And it explains how users keep a working product while the work happens. If a rewrite really is the right call, a good reviewer can show you why in plain English, pointing at real problems in the code.

If your product was built with AI tools, see hiring a developer for an AI-generated app. For a second opinion before you commit, tell me about your product.

Sources

Things You Should Never Do, Part I (the Netscape rewrite), Joel on Software
Strangler Fig Application, Martin Fowler