Signs your MVP needs a rescue, and what to do in the first two weeks

Products rarely fail in one dramatic moment. They drift. A two-week task takes six. Every release breaks something that used to work. The developer who built most of it becomes hard to reach. If this sounds familiar, the product may need a rescue, and the way you handle the first two weeks decides whether it recovers or turns into an expensive rewrite.

Signs it is time to act

• Estimates keep slipping and nobody can explain why in plain language.
• Releases are scary. The team avoids deploying, or deploys late at night and hopes.
• The same bugs come back after being marked as fixed.
• One person holds all the knowledge, and you do not have admin access to the code, servers, or app store accounts.
• Customers find problems before the team does, because there is no monitoring.

Any one of these can happen in a healthy project. Three or more at the same time usually means the problem is structural.

Days 1 to 3: secure access

Before anything technical, make sure your company controls its own assets: the code repository, hosting and cloud accounts, the domain and DNS, app store accounts, payment provider, email sending service, and any third-party API keys. Each should be owned by a company account, with at least two people able to sign in.

This is not about distrust. It is about making sure the business can continue whatever happens with any individual, including the people trying to help.

Days 3 to 7: establish the facts

Resist the urge to judge the code by how it looks. Instead, collect facts:

1. Can a new engineer get the project running on their machine from the instructions alone?
2. Is there a separate staging environment, or does every change go straight to customers?
3. Are there backups, and has anyone ever tested restoring one?
4. Which parts of the product cause most of the bugs and support requests?
5. Are there obvious security gaps, such as passwords in the code, admin pages without proper login, or outdated dependencies with known vulnerabilities?

The answers produce a short, honest map: what is solid, what is risky, and what is actively hurting users.

Days 7 to 14: one stable release

The first goal is not new features. It is one release that goes out calmly and does not break anything. In practice this means a staging environment, a repeatable deployment, basic error monitoring, and fixes for the two or three issues that hurt users most.

That first calm release changes the mood of the whole project. The team regains confidence, customers see improvements, and you get a realistic sense of how fast the product can move.

Rewrite or repair?

Founders often ask on day one whether everything should be rebuilt. Sometimes it should, but that is a conclusion to reach after the facts, not before. A rewrite pauses progress for months and carries its own risks. Most products are better served by stabilising first and then replacing the worst parts one at a time, while customers keep using the product.

A rewrite makes sense when the foundations cannot support what the business needs next: the data model is wrong for the product, the technology is no longer supported, or the security problems are too deep to patch.

What to have at the end of two weeks

• All accounts under company control, with access documented.
• A written assessment of risks, ordered by impact on users and the business.
• A staging environment and a deployment anyone on the team can run.
• One stable release with the most painful issues fixed.
• A realistic plan for the next six weeks, with a clear recommendation on repair versus rebuild.

If your product is showing several of these signs, an outside review is often the fastest way to separate what is really broken from what is just unfamiliar.

Our Rescue & Rebuild Sprint follows exactly this order: audit, stabilise, then a written fix-or-rebuild decision. If the product was built with AI coding tools, start with a Vibe-Coded App Production Check.