Rebuild or Stabilize? What you should do with your MVP (How to Maximize Output)
Let me paint you the picture. You as the founder have a product in mind. A software that will change the game.
One problem.
When you inherit a broken product or realize the current build isn’t going to work out. Usually there’s two options:
A) Rebuild everything from scratch.
B) Patch what’s there and hope for the best.
Both can be right or wrong but there’s actually a third option. Let’s dive deep into the framework I use to make the right call.
MVP Rescue Framework
Option 1 - Rebuild from scratch
Sometimes the foundation is so broken that nothing is worth saving. The architecture, spaghetti codebase, and tech choices made were effectively wrong. They actually hinder growth than promote it.
If that’s the case, then starting from scratch is the right call. It will likely be the most expensive and time consuming, but there’s no other way out.
Be careful with this option. This option is emotionally charged because sometimes when a founder wants to move forward with a ‘clean slate’. But it can actually be a devastating move if it’s not necessary.
Think of this being the last resort.
Only take this option if it meets these requirements:
Core architecture is beyond reparable and does not align with the business needs.
Security vulnerabilities are so severe that a simple patch is not worth it.
Cost of fixing exceeds costs of rebuilding (with proper foundation).
Zero documentation and it’s incoherent.
Option 2 - Fix and improve
This is the most common scenario. Foundation is good enough but the execution is poor. The UX/UI experience is rough but the overall functionality works.
In this case, the targeted fix and improvement is the right move. You prioritize the critical problems and address them systematically.
The biggest risk here is scope creep. Many times ‘little fixes’ here and there become a ‘death by million cuts’ situation. Both the technical partner and the business should have clear boundaries and scope to avoid this.
Fix and improve when:
Core features and functionality are there but execution is rough.
Technical debt is manageable rather than catastrophic.
Budget allows for it without major constraints.
Option 3 - Stabilize & ship
This is the ‘best of both worlds' option. Here you get to fix the issues but you do in a matter that’s quicker compared to option 2.
This means that you as the founder and/or your team triage ruthlessly. You identify the ‘MUST HAVES’ and only fix that. Forget about the rest (leave it for a version 2 or 3).
This is a deliberate effort. Not so much ‘cutting corners’.
Do this when:
Budget is the constraint.
You need to market this fast or maintain momentum.
There’s a clear technical path for the subsequent versions for the future.
What happened in my experience
In last week’s newsletter I mentioned that a client came to us after their developer disappeared.
When I sat down with the team we had a real conversation regarding priorities and how that would shape their MVP.
After diagnosing and taking a further look into their software a full rebuild was the ideal solution. However, this was not viable. Time and budget constraints said otherwise.
Our team went ahead and spearheaded with option 3.
Our main concern here was: ‘What are the must haves for this MVP?’
The biggest one by far is fixing the database and data. How are the users supposed to use the app if they can’t even use the most valuable asset of the app? We refreshed the data, created an internal automation, and fixed all errors in the database.
The second in priority was core functionalities such as the filtering for the data.
Lastly we handled all broken pages and links. Everything else is deferred until version 2 and beyond.
What was the result? Happy clients and an MVP that was launched quickly and functioning properly.
Bottom Line
Rebuild, fix, or stabilize. Three options. One right answer depending on your specific situation.
The founders who make this decision well are the ones who separate technical idealism from business reality and find a technical partner who can do the same.
I hope this helps in building your MVP.
Thanks for reading.
- Andres