Fix or rebuild? What to do when your MVP build has stalled

Your MVP was supposed to be live by now. Instead, every update brings a new delay, small changes break other things, and nobody can explain the problem in words you understand. One founder described their build as "not at all according to mutually agreed specifications" (HN). Another put the effect more simply: "Quite the momentum killer." (HN)

At this point most founders ask one question: should we fix what we have, or start again? It is the right question, but it comes third. Two steps come first, and they make the answer far easier to reach.

This guide walks through those steps in order, then shows how to brief the next team.

Step 1: Secure everything you own

Before anyone judges the code, make sure you control it. This is not an accusation. It removes the risk that a dispute or a closed company locks you out of your own product.

Check that each of these sits in an account you own, with your company email as the administrator:

• The code repository. This is where the source code and its history live, usually on GitHub, GitLab or Bitbucket.
• Hosting and databases. The cloud accounts where the app runs and where customer data is stored.
• Domains and email. The registrar account that controls your web address, and the DNS settings that point it at your app.
• Third-party services. Payments, email sending, analytics, app store listings and anything else the product calls.
• Secrets. The passwords and API keys the app uses to reach those services, often kept in files called environment variables.
• Design files and documents. Specifications, designs, decisions and any notes on how to install and run the product.

If an account is in the team's name, ask for a transfer rather than a shared login. Then change the passwords and keys yourself once the transfer is done.

Hi [name],

As we plan the next phase of [product name], I'd like every asset under our company's ownership. Could you help with the following by [date]?

1. Transfer the code repository to our organisation account [account name], including full history and all branches.
2. Add [your email] as owner on hosting, database, domain and DNS accounts, or transfer them to us.
3. Share a list of every third-party service the product uses, with the account owner for each.
4. Share the environment variables and any keys needed to run the product, through [password manager or secure method].
5. Send written steps to install, run and deploy the product from scratch.
6. List known issues, unfinished work and any shortcuts you would revisit.

This is standard housekeeping and does not change our current arrangement. Thank you.

[your name]

Step 2: Agree how the product should work before judging the code

A code review asks whether the code does what it should, in a way that can be changed safely. If nobody has written down what it should do, the review has nothing to measure against.

So before the review, describe the intended workflow. Pick the one journey that matters most for the first release, for example: a new customer signs up, books a session and pays. Write it as numbered steps from the user's point of view.

Then make it visible. A clickable prototype lets you, your cofounder and any reviewer agree on the target without reading code. You can sketch one in Runwise Studio, which turns a described workflow into an editable scope and a browser prototype. That prototype is a planning tool, not production software, and its job here is to settle what the product is meant to do.

With an agreed target, the review can say something precise: "the booking step works, but payments do not match the agreed flow". That is far more useful than "the code is messy".

Step 3: Read the signals for fixing or rebuilding

Ask an experienced engineer independent of the current team to review the code against the agreed workflow. Ideally they have no stake in the follow-on work, or they state it openly.

1. Can you install and run the product from the written instructions alone? What was missing?
2. Which steps of the agreed workflow work today, which work partly, and which are missing?
3. Are there automated tests, and do they pass?
4. Is any customer data exposed or unprotected?
5. Which parts would you keep, change or replace?
6. How hard would this next change be: [describe one planned change]?
7. What would make you lean towards fixing or rebuilding, and what would you need to see to be sure?

Treat the answers as signals, not certainties. Two good reviewers can read the same code differently, and both can be reasonable.

Signals that point towards fixing

• The product runs, and most of the agreed workflow already works.
• The problems are concentrated in a few areas rather than spread everywhere.
• The reviewer can make a small change without breaking unrelated parts.
• The technology is common and well supported, so other developers can pick it up.

Signals that point towards rebuilding

• Nobody can install and run it reliably, even with the instructions.
• The structure does not match the workflow you agreed, so most features would need reshaping anyway.
• Every change breaks something unrelated, and there are no tests to catch it.
• Customer data handling has serious gaps that would be hard to close in place.
• The technology is obscure or abandoned.

Often the honest answer is a mix: keep some parts, replace the ones that block progress. A rebuild without a clearer target can end up in the same place.

If your MVP was built with an AI coding tool

AI coding tools can produce a working demo quickly. The difficulty usually appears when real users, payments and edge cases arrive. As one developer put it, "Vibe coding is a myth, it will take you only so far" (HN).

The steps above apply, with extra checks:

• Ownership. Make sure the project is exported from the tool into a repository you own, and that hosting is not tied to a personal trial account.
• Secrets. Check that API keys are not written into code that runs in the browser, where anyone can read them.
• Data access. Ask the reviewer to confirm that one user cannot see another user's data.
• Consistency. Generated code may solve the same problem several ways. That is often fixable, but the review should name it.

A prototype built with an AI tool can also serve as a strong description of intent for Step 2, even if the code itself is replaced.

Step 4: Choose and brief the next team so the pattern does not repeat

Whether you fix or rebuild, the next team needs a clearer starting point. Stalled builds often share a cause: a vague target, progress reported rather than shown, and unclear ownership.

Brief the next team with the agreed workflow, the prototype, the review findings and the first change you want. The Runwise brief builder can help you put those into one document.

Ask candidates how they work, not only what they have built:

• How will we see working software, and how often?
• Who owns each account from day one?
• What does "done" mean for a feature, and who accepts it?
• What will you hand over if we stop working together?

Good answers are specific and written down. If a team cannot describe its handover before starting, expect it to be harder at the end.

Common mistakes

• Starting the review before securing access. Transfer the accounts first, so the review cannot become a point of leverage.
• Asking the current team to judge its own work. Their view matters, but pair it with an independent review against the agreed workflow.
• Rebuilding without a clearer target. Agree the workflow and prototype it first, or the new build can drift the same way.
• Treating the decision as all or nothing. Ask which parts to keep, change or replace, then decide area by area.
• Hiring the next team on the portfolio alone. Test how they show progress, define done and hand over, and write it into the agreement.

Questions founders ask

Your next step

This week, send the handover request and confirm you own the repository, hosting, domain and service accounts. Then write down the one workflow that matters most for your first release, so that any review you commission has a clear target to measure against.