The last person left. An agency looked at the repo for an hour and quoted a rewrite. The product still has to run on Monday. Taking over an existing product without a rewrite is the job I actually get asked to do — not a greenfield build with a blank Figma file.
I take this work on all the time, across websites, SaaS, and products that already have users. Starting over feels clean. It is also how you spend six months to get back to where you were in week two, minus the customers who got tired of waiting. Here is how I take over what's there instead.
Why a rewrite gets sold
A rewrite is easy to sell because it has a simple story: the old thing is messy, the new thing will be clean, and you won't have to think about the mess again. The story skips the part where the messy thing is currently taking money, and the clean thing doesn't exist yet.
It also skips the part where most of the mess is not the code. It is the missing password for the domain, the payment account in someone else's email, the feature nobody wrote down because "everyone knew." A new repo does not fix that. It just gives you a second place to lose it.
What I look at in an existing product
Before I write a line, I want four things named. This is the same discipline as scoping a project before I quote — except the artefact already exists, so the brief has to describe reality, not a hoped-for version of it.
- 01
Who uses it on a Monday
Not the deck version. The person who logs in, the checkout that still takes money, the report someone opens every week. If I can't name that person, I don't know what I'm allowed to break.
- 02
What already works
Rewrites get sold by listing what's wrong. I start by listing what must not move: payments, login, the one flow that pays the bills. Those stay live. Everything else is a candidate, not a target.
- 03
Where it actually hurts
Slow, flaky, a feature that never shipped, a deploy nobody wants to touch. Pain is not the same as architecture. A page that takes four seconds is often an afternoon. A rewrite is a year. I want the afternoon first.
- 04
What I can actually see
Repo access, hosting, env vars, the domain, the analytics, the last deploy. A product with no access is not a product I can take over. It's a rumour. If the last person left a zip file and a half-paid invoice, I start by getting the keys, not by drawing a new system.
On a Next.js app the first pass is often boring on purpose. The cheap wins I wrote down in App Router mistakes — a client boundary in the wrong place, images without dimensions, metadata typed twice — are afternoon work with month-long payoffs. They are also the opposite of a rewrite. You keep the product. You remove the drag.
When rewriting an existing product is justified
I'll say so. Pretending every codebase can be saved is how you become the next person who leaves. These are the cases where starting over, or replacing a piece for real, is the honest call.
- 01
The platform is actually dead
Not unfashionable. Dead. The language is unmaintained, the host is shutting down, or the thing cannot take a payment because the provider killed the API. That's a forced move. It's also rare. "It's old" is not the same sentence.
- 02
Nobody can change a line without it falling over
If every small fix risks the checkout, the product is holding you hostage. Even then I don't start with a blank repo. I isolate the dangerous part, put a fence around it, and replace that piece. The rest of the product keeps running.
- 03
The product is the wrong product
Sometimes the software works and the business doesn't. That's not a rewrite. That's a different brief. Building a second version of the wrong thing, cleaner, is how you spend a year to arrive at the same stuck place.
A rewrite is a last resort, not a personality. Most of the time the honest answer is repair.
How a takeover runs while the product stays live
Access first. Then a written cut line: what stays, what gets repaired, what waits. Then work that can ship behind the same URL, in pieces small enough that a bad week doesn't take the shop down. That is the whole method. It is also what I own as a full-stack developer on this kind of job — interface, systems, production — inside a product that already has a shape, not a blank one.
Rewrite
The live product waits
Months of parallel work, a big cutover, and a prayer that you remembered every edge case.
Takeover
The live product stays the product
Small landings, the same URL, and a list of what must not break this week.
You can see this shape in products I've already taken further — not every case study started from zero. Some of them started as a site that looked finished and behaved badly, or a first version that had customers and a lot of debt. The rest of taking over a product is that situation from different angles, and most of shipping comes back to the same cut: keep the thing in the world while you make it better.
