"MVP" gets treated as a speed goal — build something, ship it, learn. That's the right instinct, but it quietly skips the harder question: an MVP built fast in the wrong shape doesn't save a founder time, it just moves the expensive mistake earlier. The goal isn't "build fast." It's "learn what actually matters, as cheaply as possible, without accumulating debt that makes the next version harder to build."
Here's how we actually think through this with founders before writing any code.
Start with the one thing that has to be true
Every product idea rests on an assumption that, if wrong, means the rest doesn't matter. Before scoping features, we push founders to name that assumption explicitly. Not "will people use this app" in the abstract, but something specific and testable: "will a small business owner pay for automated inventory alerts" or "will a patient actually complete a booking flow inside a chat interface instead of calling."
The entire point of an MVP is to test that one assumption as directly and cheaply as possible. Everything that doesn't serve that test is, by definition, not part of the MVP — even if it feels important.
The features founders want to cut but shouldn't
Some things get labeled "we'll add that later" that genuinely can't wait, because they're structural rather than additive:
- Basic authentication and data separation — even an MVP handling real user data needs this done properly from day one. Retrofitting security after real users are on the platform is far more expensive than building it correctly the first time.
- A data model that won't need to be rebuilt — the underlying database structure doesn't need every field the final product will have, but it needs to be shaped correctly enough that adding features later doesn't mean migrating everything.
- A way to actually see what users are doing — even lightweight analytics or event logging. Without this, the "learn" part of build-measure-learn doesn't happen; founders end up guessing instead of knowing.
The features founders want to keep that should get cut
The opposite mistake is just as common — holding onto features that feel important but don't actually test the core assumption:
- Admin dashboards with every possible view, built before there's enough usage data to know which views anyone needs
- Support for edge cases and rare user types that might matter eventually but aren't part of the core loop being tested
- Polished onboarding flows for a product that hasn't yet proven anyone wants to get past step one
- Multiple integrations planned "because customers will probably ask" rather than because a specific early customer has asked
The pattern here: build for the users you have or are actively talking to, not the hypothetical users you're hoping to attract six months from now.
Where AI fits into MVP timelines
AI features are increasingly part of MVP requests, and the same discipline applies. If the AI feature is the core assumption being tested — "will people trust an AI-generated summary of their finances" — it needs to be built properly, even in an MVP, because a broken version of the core hypothesis gives you a false negative. If it's a nice-to-have layered on top of a different core assumption, it can usually wait for version two without weakening what you're actually trying to learn.
What an 8-week MVP timeline actually looks like
For a reasonably scoped MVP, here's roughly how the time tends to break down when we work with founders:
- Weeks 1-2: Scoping and architecture. Nailing down the one assumption being tested, mapping the minimum data model and user flow that tests it, and making the handful of technical decisions (stack, hosting, auth approach) that are expensive to reverse later.
- Weeks 3-6: Core build. The actual feature work — deliberately narrow, built against the real data model from week 1-2, not a throwaway prototype that gets rebuilt later.
- Weeks 7-8: Testing, polish on the critical path only, and launch prep. Fixing what's broken in the core flow, not adding features. Polish gets applied only to the path a real user will actually walk through first.
The founders who get the most out of this timeline are the ones who resist the urge to expand scope mid-build when a "quick addition" starts sounding tempting. Almost none of those additions are actually quick, and almost all of them delay the point where you learn whether the core idea works.
The honest advice
If you're a founder about to start an MVP, the most useful conversation to have with a development partner isn't about the feature list — it's about which single assumption the MVP needs to test, and what's the smallest, most honest version of the product that actually tests it. Everything else is a decision you get to make later, once you have real users telling you what they actually need.