Maulik Bdani
An MVP's job is to answer one question as cheaply and quickly as possible: will people actually use, and pay for, this thing? Everything else is secondary to that.
Build the smallest thing that proves the idea
Cut every feature that isn't essential to testing the core hypothesis. It's tempting to build the full vision from day one — we get that pitch in almost every founder call — but investors want evidence the core idea works, not a polished product with zero users behind it.
A founder we worked with insisted early on that their MVP needed a full admin dashboard before launch. We pushed back, shipped without it, and manually handled the handful of admin tasks ourselves for the first six weeks. Nobody ever noticed the dashboard was missing, because there were only nine users to manage by hand.
Let real usage guide the roadmap
Ship early, instrument everything, and let actual user behavior — not internal opinions in a Slack thread — decide what gets built next. The MVPs that attract funding are consistently the ones with real usage data behind every roadmap decision, not the ones with the longest feature list in the pitch deck.
What investors actually want to see
Investors have sat through hundreds of pitches with polished mockups and zero traction. What consistently stands out is a small number of real users doing the core action repeatedly — logging in, completing the workflow, coming back the following week without being reminded. That single retention curve, even a modest one, tells a more convincing story than a hundred-slide deck describing a five-year vision nobody has tested yet.
- Define the one core action that proves your hypothesis, and build only what's needed to let a user complete it.
- Instrument that action from day one — you can't show traction you didn't measure.
- Talk to your first 20 users personally rather than relying on analytics alone for the first few weeks.
- Track week-over-week retention on the core action, not just signups — signups are easy, return usage isn't.
- Treat every feature request from a single user as a data point, not a mandate, until it repeats across several.
Common ways teams overbuild anyway
Even founders who understand the theory tend to overbuild in one specific area: whatever part of the product they personally find most interesting to build. Engineers over-engineer the backend for a scale they don't have yet. Designers polish onboarding flows for a userbase still in single digits. The discipline isn't just 'build less' in the abstract — it's noticing your own bias toward the part of the build you enjoy most and cutting there first, since that's usually where the unnecessary scope is hiding.
A tightly scoped MVP built in weeks, with clear metrics on engagement, is far more fundable than a feature-complete product that took a year and still has no users to point to. The goal isn't to build less forever — it's to earn the right to build more by proving, cheaply, that the core idea holds up against real behavior first.
What happens after the MVP validates
Validation isn't the finish line — it's the point where the roadmap conversation actually gets easier, because decisions stop being guesses and start being informed by real behavior. The mistake we see even in successful MVPs is treating the validated version as the final architecture and building the next two years of features directly on top of code that was deliberately written fast and disposable. A short, deliberate rebuild phase once the core hypothesis is proven — cleaning up the parts that were built to be thrown away — tends to save far more time over the following year than skipping it does.
Handling feedback that contradicts the data
Early users will sometimes give strong, specific feedback that contradicts what the usage data is actually showing, and knowing which one to trust is one of the harder judgment calls in MVP development. Our rule of thumb: individual feedback is useful for identifying friction and generating hypotheses, but usage data across the full early cohort should decide what actually changes. A single vocal user asking for a feature the rest of the cohort shows no sign of needing is a data point worth noting, not a mandate worth building around immediately.
Communicating progress to non-technical stakeholders
Founders reporting to a board or early investors often struggle to translate 'we shipped a scoped-down MVP and are watching usage data' into language that reassures people expecting a more traditional product roadmap. We help clients frame this explicitly as a deliberate risk-reduction strategy — spending less to learn faster — rather than letting it read as a smaller, less ambitious version of the original vision. The framing matters as much as the substance in keeping stakeholders aligned through an MVP phase that can otherwise look, from the outside, like scope was simply cut.
Avoiding the trap of building for imagined scale
It's tempting to architect an MVP's backend for the scale the founder hopes to reach eventually, and we've had to talk more than one technically strong founding engineer out of building infrastructure sized for ten thousand users when the actual current cohort is a few dozen. That instinct usually comes from good engineering discipline applied at the wrong moment — the infrastructure that matters at scale is rarely the bottleneck to proving the idea works in the first place, and over-engineering it early just slows down the validation the MVP is supposed to be racing toward.
The founders who navigate this best treat the MVP phase as a genuinely temporary state, not a permanent operating mode. Knowing when validation has happened and it's time to invest more seriously is its own decision worth making deliberately, rather than staying in scrappy MVP mode out of habit long after the evidence has already answered the question it was built to answer.
We stay involved past the initial MVP build specifically to help founders make that call, since it's genuinely difficult to judge from inside a project whether the validation signal is strong enough to justify the next investment, or whether the more disciplined move is to keep testing a cheaper variant a little longer first.
