Should I build an MVP or validate first?

For most product categories in 2026 — single-player SaaS, prosumer tools, B2B SaaS with a clear job-to-be-done — validate first. A €200 landing-page test gives you the same yes/no signal as a 6-week MVP, with 30–50x lower cost. MVP-first remains valid for products whose value requires multi-touch interaction or network effects.

Why was MVP-first the standard advice?

Because in 2014, building was the most expensive activity in the validation loop. The MVP was the cheapest path through validation when validation-without-building was even more expensive. Inference, hosting, page-builders, and ad platforms have collapsed the cost of validation by an order of magnitude since then. The advice didn't update.

Doesn't validation only work for simple products?

It works for any product whose offer can be communicated on one page. That's most products. For genuinely experiential products (multi-player games, complex marketplaces with network effects, deeply technical infrastructure), a small interactive demo plus a landing page often beats either a pure MVP or pure validation.

What if my landing-page test fails but I think the idea is good?

That's the moment validation-first earns its keep. A clean test result that contradicts the founder's belief is exactly the information you need. Re-scope the offer, the audience, or the pricing — and run one sharply different second test. Don't rerun the same offer hoping the number drifts up; that's not validating, that's stalling.

How long does validation take vs an MVP?

A complete pre-MVP validation runs 10–14 days end-to-end (page, ads, decision). The smallest credible MVP, even with 2026 tooling, is 4–8 weeks. Information yield is roughly equivalent — both tell you whether strangers convert. The validation path is 3–4x faster on average.

Validate Before MVP: Why Most Founders Have It Backwards

Open any startup textbook from 2014 and you'll find some version of the same advice: build an MVP, ship it, learn from real usage. It was good advice. In 2014.

In 2026, it's almost always wrong, and the reason has nothing to do with whether MVPs work in principle. It has to do with how building costs have collapsed since the advice was written.

This is the argument. The MVP-first sequence — build first, validate after — was a heuristic that made sense when building was the bottleneck. Building isn't the bottleneck anymore. The sequence inverted, but the textbook didn't.

The original logic, and why it worked

Here's why "build the MVP, then validate" was correct in 2014.

Building was hard. A two-developer team needed 6–12 weeks to ship a credible v1 of anything. Hiring contractors cost $20k. Building yourself cost a season. Either way, the building was the most expensive activity in the loop.

Given that constraint, the optimal move was to build the minimum version first — strip features ruthlessly, ship something embarrassingly small, learn from real users. The MVP was a way to get to validation cheaply, when validation-without-building was even more expensive than validation-with-an-MVP.

This logic was articulated in The Lean Startup (Ries, 2011), and it traveled. By 2014 it was orthodoxy. By 2018 it was on every YC application. By 2022 it was being parroted on every founder podcast in the world.

It worked. It worked precisely because of the underlying cost structure. Building was expensive; validation was relatively expensive too; minimum viable product was the cheapest path through both.

What changed: building costs collapsed faster than anyone updated their advice

The cost of shipping software dropped by something like an order of magnitude between 2020 and 2026.

A working prototype that took six weeks of contractor time in 2014 now takes a long weekend with Cursor or Lovable. Stripe + Vercel + Supabase + Auth.js = a paid B2C SaaS deployed to production in a Saturday. The bottleneck moved.

Meanwhile, validation tooling also improved. A landing page that took a week to build in 2014 now takes an hour. Paid ad platforms (Meta, Reddit) became self-serve. Conversion-tracking became default.

So the question changed. It used to be: what's the cheapest way to learn whether anyone wants this? Building an MVP. Now it's: what's the cheapest way to learn whether anyone wants this? Running a €200 paid-traffic test on a landing page.

The MVP didn't get more expensive. The alternative got dramatically cheaper. That's the inversion most founder-discourse missed.

The case for validating first, in 2026

Three reasons.

1. The validation test is now 30–50x cheaper than the smallest MVP

A complete pre-MVP validation — landing page, ad spend, conversion measurement — runs €150–€300 and takes 10–14 days. The smallest credible MVP, even with 2026 tooling, is 4–8 weeks of work and probably €0 cash but real opportunity cost.

Comparing strictly on time: 14 days vs ~50 days. On information value: roughly equivalent (both tell you whether strangers convert). On preserved optionality: validation-first preserves the ability to walk away cleanly; MVP-first locks you in emotionally.

The MVP path has no information advantage to justify the time cost.

2. MVP-first overcommits you emotionally before the data comes in

There's a psychological mechanism at play. Building anything — even a tiny MVP — produces small wins along the way. Auth working. The first deploy. A login screen that looks halfway clean. Each of these triggers a small reward and ties the founder a little more tightly to the project.

By the time the MVP is live and the founder finally goes to validate, they've spent 60+ hours and have an emotional stake. If usage is poor, they don't conclude "the idea was wrong." They conclude "the MVP was wrong." Then they iterate on features instead of questioning the premise.

We've watched this pattern play out dozens of times. The MVP-first sequence locks founders into an idea before the market has rendered a verdict.

Validation-first reverses the order. The verdict comes back when the founder has spent €200 and 14 days. Walking away costs almost nothing.

3. MVP signal is contaminated by build quality

Here's a subtle point. When you ship an MVP and watch usage, you can't distinguish "the idea is bad" from "the MVP is bad."

Low retention could mean nobody wants this; could also mean the onboarding sucks. Low conversion to paid could mean the offer is wrong; could also mean the pricing page is broken. MVP signal is muddy because the product is the variable.

Pre-MVP signal is cleaner. The landing page is just the offer. If conversion is low, it's the offer. There's no "but the build wasn't good enough" defense to hide behind.

This matters because the founder's natural bias is to keep the idea alive. Muddy signal feeds that bias. Clean signal doesn't.

The honest counter-argument

The strongest case for MVP-first comes from product categories where the experience of using the product is the value proposition.

For complex multi-touch B2B products, marketplace dynamics, social products with network effects, or anything where the value only emerges after a few interactions — a landing page genuinely can't communicate the offer. People will say "yes, sounds great" without grasping what they're signing up for.

In these cases, MVP-first has merit, but with a modification: build the smallest version of the interaction that produces the value, not the smallest version of the product. A two-page demo with one working interaction beats a half-built MVP every time.

But for most ideas — single-player SaaS, prosumer tools, AI products with a clear job-to-be-done — the landing page communicates the offer perfectly well, and validation-first wins by a large margin.

What changes when you validate first

A few things shift in your founder workflow once validation comes first.

You generate more ideas. When validation costs €200, killing an idea isn't a defeat — it's just data. Founders who validate first cycle through 4–6 ideas a year. Founders who MVP first cycle through 1, sometimes 2.

You become honest faster. The first three days of paid traffic tell you something. By day seven you usually know. The illusion that "it just hasn't found its audience yet" doesn't survive a clean conversion-rate read.

You build better products. This is counterintuitive. The validation step forces you to articulate the offer with extreme clarity (you have to write a press release, an ad headline, a landing-page hero). That clarity carries forward into the build. Products that come out of pre-MVP validation tend to have crisper positioning than products that come out of MVP-first iteration.

Most ideas that go through MVP-first die at month four or five, after eating two seasons of nights and weekends. Most ideas that go through validation-first die at week two, after eating €200 and a long weekend. Both produce the same answer. One costs roughly 40x more.

The two-question test

If you're not sure whether to validate first or MVP first on a specific idea, two questions:

Q1: Can you describe the value the customer gets in one paragraph that they'll understand? If yes, the offer is communicable on a landing page. Validate first.

Q2: Does the value require multi-touch interaction, network effects, or experiential demos to land? If yes, validation-first is harder. Consider MVP-first with a tiny interactive demo, not a full product.

In our experience, 80% of the ideas founders are working on right now answer "yes" to Q1 and "no" to Q2. Those ideas should validate first. Almost all of them.

A worked example

A founder we know was building a B2B procurement tool. Six weeks into the MVP, he had auth, a dashboard, and a half-implemented vendor catalog. He paused to do user research. The interviews said the procurement managers loved the idea. He kept building.

Three months in, he launched. Eight signups. Three trials. Zero conversions to paid. He spent the next two months "iterating" — new pricing, new onboarding, new dashboard. Still zero conversions.

We ran the numbers backward. He'd spent five months and could have validated the same offer in 14 days, with €250 of LinkedIn ads to a landing page promising the procurement features. The conversion rate to "book a demo" would have told him in week two what five months of building told him in month five: the offer was wrong for the audience he could afford to reach.

He killed the project, applied the same playbook to a different B2B idea, and validated cleanly in 11 days. He's now at 18 paying customers six weeks after starting the build. The validation step compressed his cycle by 4 months.

How LemonPage fits

The single biggest reason founders skip validation-first isn't disagreement with the logic — it's friction. Setting up the page, the ads, the analytics, the kill criterion in different tools takes hours. By the time the test is configured, the urge to "just build the MVP" wins.

LemonPage collapses the configuration into one workflow. It doesn't change the math — it removes the friction that lets the math get ignored.