Almost every founder we talk to already knows they should "build an MVP first." The advice isn't the hard part. The hard part is that nobody agrees on what actually belongs in it — and getting that scoping decision wrong is one of the most expensive mistakes we see, in both directions.
Teams tend to fail one of two ways. The first: treating "MVP" as permission to build something so thin it can't actually validate anything — a login screen and a form isn't a test of your idea, it's a test of whether people fill out forms. The second, more common failure: quietly turning the MVP into the full product, adding "just one more" feature until the thing that was supposed to ship in six weeks ships in six months, having spent the budget before learning whether anyone wants it.
Instead of listing features and arguing about which ones are essential, we ask a different question: what is the single riskiest assumption in this business, and what is the smallest thing we could build to test it honestly? For a marketplace, that's usually "will supply and demand actually meet" — not a polished checkout flow. For an internal tool, it's usually "will the target team actually change their workflow to use this" — not a full permissions system.
The one path that matters most — the thing a user does start to finish to get the core value — deserves real polish. A rough MVP with a broken core flow teaches you nothing, because people bounce before they experience the thing you're trying to validate.
Admin dashboards for internal use, most account settings, social login (email/password is fine to start), notification preferences, and anything "for scale" — sophisticated caching, microservices, multi-region deployment — before you have evidence you need it. We've seen teams spend a third of their MVP budget on infrastructure built for a scale they were, realistically, a year or more away from.
A real MVP will feel uncomfortably incomplete to the person who built it. That discomfort is a feature, not a bug — it means you've actually cut to the core rather than building a slightly-smaller full product. If your MVP feels comfortable and complete, it probably isn't one.
We start by writing down the riskiest assumption explicitly, then work backward to the smallest build that tests it honestly — not the smallest build that's technically possible, which is usually too thin to learn anything from.