Fix an unfinished app unless its data model or core architecture is wrong for the product it needs to become. Most stalled apps have working parts worth keeping. Assess the product, the code and the launch gaps first, sort each part into keep, fix or replace, and replace parts in stages rather than starting over.

Picture a founder eight months into a marketplace app. The first developer left, a second added features with an AI coding tool, and now the app mostly works in the demo but breaks in ways nobody can explain. A new team looks at the code and says what new teams often say: "It would be faster to rebuild." Maybe it would. But the founder has heard that before, and the last rebuild is how they got here.

What is the difference between fixing, rebuilding and replacing in stages?

Fixing keeps the existing codebase and closes its gaps. Rebuilding throws it away and starts again. Replacing in stages sits between the two: the app keeps running while its weakest parts are swapped out one at a time.

• Fix: keep the code, data and infrastructure, and repair what is broken or missing. This is the right default when the core works and the gaps are known.

• Rebuild: start a new codebase and move users and data over when it is ready. The old app stays frozen or limps along in the meantime.

• Replace in stages: build new parts next to the old ones and move behaviour over piece by piece. Martin Fowler calls this the Strangler Fig Application pattern: it "begins with small additions, often new features, that are built on top of, yet separate to the legacy code base."

The choice is rarely all or nothing for the whole app. One app can need its payments fixed, its admin panel kept and its data layer replaced.

Why is a full rewrite usually the riskier choice?

A full rewrite throws away the knowledge built into the old code, and the business waits with nothing new to show until the rewrite catches up. That is why it should be the exception.

Joel Spolsky made the case in 2000 in Things You Should Never Do, Part I, calling a rewrite from scratch "the single worst strategic mistake" a software company can make. His reason still holds: "Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed." Code that looks messy often looks that way because it handles cases someone found the hard way.

Fowler makes a related point: replacing a system "seem[s] easy to specify, but often it's hard to figure out the details of existing behavior." A rewrite team has to rediscover every edge case, and users can't wait while they do.

AI-built apps change this a little. Code written quickly by an AI tool may have seen fewer real users, so there are fewer hard-won fixes to lose. But the same tool that wrote it fast can rewrite it fast and stall in the same place, for the reasons covered in Why Projects Built With Claude or Codex Stall Before Launch.

How do you assess an app you didn't build?

Assess it in three parts, product, tech and launch, before anyone gives an estimate. A takeover assessment is a short, structured review that ends with a list of what to keep, fix and replace, and why.

Product: are the core user journeys complete?

Walk through every journey a paying user needs, from sign-up to the outcome they came for, on a real device with realistic data. Note where a journey dead-ends, needs a workaround or depends on someone fixing data by hand.

Tech: can you keep building on it?

Read the code before judging it. Check the data model, authentication and permissions, how payments and other money-moving actions are handled, whether there are tests, and whether you can set up the app from the repository alone. Ask what a small change costs today: if adding a field takes a day of untangling, that is the number to record.

Launch: is it ready for real users?

Check hosting, environments, backups, monitoring, error logging, analytics and the integrations the business depends on. Many apps that work in the demo have none of these. Our post on what breaks when an AI-built app gets real users lists the usual gaps.

What to ask for before you start

1. Access to the repository, hosting, database and every third-party account.

2. Any written spec, design files or instruction files the previous team or AI tool used.

3. A list of known bugs and the workarounds users already rely on.

4. The person who knows the business rules, for an hour.

When is a rebuild the right call?

Rebuild when the foundation is wrong for where the product is going, not when the code is merely untidy. These are the signals that usually justify it:

1. The data model can't represent the business. For example, the app assumes one user per account and the product now sells to teams. Every feature built on top inherits the mistake.

2. Security can't be patched in. Access rules were never designed, so every query and screen would need rework anyway.

3. The platform is a dead end. The app runs on a tool or framework that can't do what the product needs next, and there is no way to export or extend it.

4. Nobody can run it. There is no repository history, no way to deploy it again, or key parts depend on an account nobody can access.

5. The product itself changed. What users need now is different enough that most existing screens and flows would go anyway.

If only one part of the app shows these signs, replace that part and keep the rest. Even a full rebuild should keep what the old app taught you: the data, the business rules, the edge cases and the list of things users complained about.

What should the first 30 days of a takeover look like?

The first 30 days should make the app safer and more predictable before they make it bigger. A reasonable plan has four steps, each finished before the next starts.

1. Get control. Move every account, domain and credential to the owner's name. Set up a staging environment, backups and error alerts. Nothing ships until this is done.

2. Assess and decide. Review product, tech and launch as above, then write down what is kept, fixed and replaced, with the reason for each. Share it with the founder before any feature work.

3. Stabilise. Fix what loses data, money or trust first: authentication, permissions, payments and failed background jobs. Add tests around the journeys that already work so that later changes don't break them.

4. Ship one visible improvement. Release a small, real change through the new process, from staging to production. It proves the team can change the app safely, which matters more in month one than any single feature.

New features come after this. Teams that skip to features usually spend month two fixing what they broke in month one.

How we approach it at Vizio AI

We start from the assumption that the app should be finished, not rebuilt, and change our minds only when the assessment gives a reason. Our Finish Your Build work follows four steps: review the product, code and architecture; diagnose what to keep and what to fix; finish the critical gaps while keeping what works; then stabilise, test, deploy and put it in front of users.

In the review we look at the same three areas this post describes, which we call the three unfinished systems: the product, the tech and the launch. The decision to keep, fix or replace is made part by part and written down, so the founder can see why each call was made and challenge it. When part of an app does need replacing, we replace it in stages while the rest keeps running.

This sits in our Venture Studio. If you have an app that stalled before launch, the Finish Your Build page is where to send it.

Sources

• Joel Spolsky, Things You Should Never Do, Part I (6 April 2000): https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

• Martin Fowler, Strangler Fig Application: https://martinfowler.com/bliki/StranglerFigApplication.html

• Vizio AI, Finish Your Build: https://www.vizio.ai/finish-your-build