How Minimal should an MVP be?
I see a lot of advice that your Minimum Viable Product (MVP) doesn’t need to be built right, that speed trumps everything else and that you’d throw it away and rewrite it correctly anyway, so why waste time on tests, architecture, modularity etc.
Now given that at AICE Labs we promise to help you “build it right”, how do we think about that? If you were to engage us for your AI initiative, would we waste the first three months drawing up the perfect architecture diagram? Nope. Building it right does not mean wasting time on the dreaded “big upfront design”. Instead, it means being crystal clear about a few things:
What stage of the product or initiative are we in?
What is the greatest open question, the greatest uncertainty, the greatest source of risk?
Based on the current stage, what’s the smartest way to answer the question, resolve the uncertainty, mitigate the risk?
Based on the stage and the question, the answer may very well be: “Throw together a vibe-coded prototype in an afternoon or two and show it to someone who fits your ideal customer profile.”
But for another stage and another question, the answer could be: “Start building a system that’s properly architected for your current stage (without closing doors for the next stage), and put it into production.”
When taken at the surface level, the “M” in MVP gets auto-translated to “A crappy version of the product”. That’s missing the point in both directions:
Go even more minimal for market risk
If you’re confident that you can build it, the biggest uncertainty is about whether someone would buy it. To verify that, a truly minimal way to test that is just a list of questions to ask potential customers, or a website describing your product with a waitlist signup form. In that case, you don’t need to waste any time on building, not even “quick and dirty”.
Go less than minimal for product risk
If you’re not sure if you can build it, the biggest uncertainty is about technical feasibility. In that case, your MVP needs to be quite a bit more concrete than a prototype, especially in situations where the leap from “looks nice in a demo” to “actually works” is large. AI, anyone?
And as experience shows, as soon as you’re building something over the course of multiple sessions, you can no longer trade quality for speed. In fact, the opposite is true. Quality reduces rework, regressions, and cognitive load, which all leads to faster results.
