Scoping an MVP down to the one workflow that needs testing

Founders almost always describe their MVP as smaller than it actually is. "Just a basic version" of a marketplace still usually means user accounts, listings, search, messaging, and payments, five separate systems that each take real time to build well. The scoping conversation isn't about cutting features randomly. It's about identifying the one assumption that, if wrong, kills the whole idea, and building only enough to test that assumption.

Every product idea rests on a handful of assumptions, but usually only one or two are load-bearing. For a two-sided marketplace, the load-bearing assumption is almost never "can we build search and filtering," it's "will supply-side users actually list their inventory without a critical mass of buyers already there." Everything that doesn't test that specific assumption is scope you can defer.

Payments, notifications, and admin tooling are usually the first things we cut, replaced temporarily with manual processes: a founder personally handling payment collection over email, or manually approving new listings for the first fifty users. It feels unscalable because it is, deliberately. The point of an MVP isn't to scale, it's to learn something real before you spend months building the parts that don't need testing yet.

Whatever the one workflow is, it needs to work completely, not partially. A booking flow that lets a user select a time slot but doesn't confirm the booking isn't a smaller version of the product, it's a broken one that will produce misleading feedback. Cut breadth aggressively. Don't cut depth on the one path you're actually testing.

Before writing any code, write down the specific number that would tell you the assumption is validated, and the number that would tell you it isn't. "People seemed interested" isn't a result. "38 percent of invited suppliers listed at least one item within a week" is a result you can act on. We build the analytics for that specific number into the MVP from day one, not as an afterthought once the product is live.

A validated MVP's codebase should become the foundation of the real product, not get thrown away. This only works if the MVP was built on a stack that scales past the pilot stage, which is why we don't build MVPs on throwaway no-code tools even under time pressure. The manual processes get replaced with real systems one at a time, in the order that actually matters for the business, not all at once.

The manual processes we deliberately leave in an MVP, a founder handling payment collection by hand, a founder personally onboarding early users one at a time, aren't just cost-saving shortcuts. They're a direct line of sight into how real users actually behave, which a fully automated system would hide behind a dashboard. We push founders to stay personally involved in every manual step during the pilot phase specifically because that proximity to real usage is where the most valuable, unplanned insights usually surface, not from the metrics dashboard alone.

Founders who delegate the manual steps too early, hiring a contractor to handle onboarding so they can focus on "strategy," often miss the qualitative signal entirely: the hesitation in a user's voice on an onboarding call, the specific wording a user reaches for when describing their problem unprompted. That signal rarely survives being summarized into a report, so we recommend staying close to it directly for as long as the pilot's manual scale reasonably allows.

There's no universal answer, but we push clients toward a specific, pre-committed pilot length, usually four to eight weeks, rather than an open-ended "we'll know it when we see it" timeline that tends to drag on without a clear decision point. Committing to a length in advance also forces a clearer definition of the specific number that would count as validation, since an open-ended pilot makes it too easy to keep moving the goalposts once real data starts complicating the original hypothesis.

Founders often arrive with two different descriptions of the same product without realizing it: the version that reads well in a pitch deck, full of adjacent features and future roadmap, and the version that's actually needed to test whether anyone wants the core thing at all. Both descriptions are honest, they're just answering different questions, one aimed at investors and one aimed at engineering. Confusing the two during scoping is where most MVP budgets quietly balloon.

We ask founders to set the pitch deck version aside entirely during scoping conversations and build only from the second question: what's the smallest version of this that would let a real user complete the core action and let us measure whether it worked. The pitch deck version is worth returning to once the assumption is validated and there's a real product to build toward, not before.

Almost every founder pushes back at some point during scoping, usually on a feature they've personally decided is non-negotiable, often because a specific early conversation with a potential customer or investor mentioned it. Rather than arguing the feature is unnecessary, we ask what specific evidence would tell them it wasn't needed for the pilot, and whether that evidence could realistically show up before or after the feature would need to be built.

Most of the time, the honest answer is that the evidence would show up during the pilot itself, which means the feature can wait until the assumption it depends on is actually confirmed. Occasionally the founder is right and the feature genuinely needs to be in from day one, usually because it's the thing being tested, not a nice-to-have around it. Either way, the conversation is more productive once it's about evidence and timing rather than a flat disagreement about whether the feature matters.