The minimum viable product, long treated as essential startup orthodoxy, has faced growing challenge from founders who deliberately skip building an actual MVP altogether, instead validating demand through other, considerably lower-cost methods before writing any actual product code at all.
Why the MVP Concept Became Startup Orthodoxy
The MVP concept emerged as a reaction against founders building elaborate, fully-featured products before validating real market demand, and the underlying insight – test assumptions cheaply before investing heavily – remains sound even as some founders now question whether building any actual product at all represents the truly cheapest way to test that underlying core assumption.
What Skipping the MVP Looks Like in Practice
Founders skipping traditional MVP development instead validate demand through simpler methods – landing pages collecting signups before any product exists, or manually delivering a service that would eventually be automated, testing actual real demand without writing any product code whatsoever.
Why “Concierge” Testing Validates Demand More Cheaply Than a MVP
Concierge testing, manually delivering a service by hand before building any actual automating technology, lets founders validate whether customers want and will pay for a specific outcome, without the real cost and time investment that even a minimal product build still requires.
The Risk This Approach Deliberately Trades Against Traditional MVP Building
Skipping product-building entirely trades away the real technical learning a MVP build provides, meaning founders choosing this leaner validation path need to build technical capability separately once real demand validation is achieved, a trade-off worth deliberately considering rather than ignoring.
Why This Approach Particularly Suits Certain Types of Startups
Pre-product validation approaches suit startups where the core risk is demand uncertainty rather than technical feasibility uncertainty, while startups facing significant technical risk may still benefit more from building a technical MVP specifically to validate that real technical feasibility question.
The Psychological Benefit of Validating Before Building
Founders who validate demand before building report a real psychological benefit – proceeding with actual product development with confidence that real demand already exists, rather than the anxiety of building first and only discovering afterward whether real market demand was ever there in the first place.
Why Investors Increasingly Respond Well to This Approach
Investors increasingly respond favorably to founders who can demonstrate validated demand before having built any actual product, since this evidence-based validation approach reduces investor risk perception considerably more effectively than an unvalidated but more polished, fully-built MVP product demo alone typically manages to achieve.
Choosing the Right Validation Approach for Your Specific Startup
Founders should choose their validation approach based on their own specific actual core risk – demand uncertainty favors pre-product validation, while technical feasibility uncertainty favors traditional MVP building – rather than assuming either approach represents an universally correct startup validation strategy independent of their own particular specific actual situation.
What a Landing-Page Test Actually Looks Like Before Any Code Gets Written
A founder testing demand this way typically builds a simple one-page website describing the product as though it already exists, complete with a pricing section and a signup or waitlist button, then spends a modest budget driving targeted traffic to that page through ads or outreach to see how many visitors actually convert into an expressed interest or a waitlist signup. A conversion rate that lands meaningfully above what similar pages in the same category typically achieve suggests real demand worth pursuing further, while a page that draws traffic but produces almost no signups delivers a cheap, early, unglamorous answer that might otherwise have cost months of product development to discover the hard way.
The Slightly Uncomfortable Reality of Concierge Testing
Founders who choose concierge testing over building described the early days honestly as more uncomfortable than the polished startup narrative usually lets on – manually doing by hand, for a handful of early paying customers, a service that will eventually be automated means admitting openly to those first customers that the “product” is, for now, just a founder personally doing the work behind the scenes. Some early customers find this transparency endearing and become unusually loyal advocates precisely because they got a direct, personal relationship with the founder during that early period. Others feel mildly misled once they realize how manual the operation still is, a tension founders choosing this path need to navigate honestly.
The approach runs into a real limit with products whose core value is inseparable from the experience of actually using a working piece of software – a collaborative tool, a game – where a landing page or a manual workaround cannot meaningfully simulate what the eventual real product will feel like to use. Some founders now run both approaches in sequence, validating raw demand with a landing page first and then following up with a scrappy concierge phase before ever writing production code, treating each stage as a progressively more expensive but progressively more reliable filter before the real product-building investment begins.
Accelerators and startup mentors who once treated a working prototype as a baseline expectation for serious founders have grown noticeably more receptive to a strong landing-page conversion number alone, a shift in what counts as credible early evidence that would have seemed unusual just a few years back.
The skepticism runs both ways, though – some experienced operators argue a strong landing page mostly proves people are willing to click a button, not that they will actually pay once a real product and a real price tag are in front of them, a gap between expressed interest and paying behavior that only a later, harder test can genuinely close.