When a Landing Page Is a Better MVP

We see founders spend months building a first version to answer a question a single web page could have answered in a week. The question is usually some form of "will anyone want this?", and software is an expensive way to ask it.

A landing page MVP is a single web page that describes a product that does not exist yet, then measures how many visitors take a meaningful next step such as joining a waitlist, choosing a plan or pre-ordering.

Eric Ries defined the minimum viable product as the version that allows a team to collect the most validated learning about customers with the least effort, and for demand questions a page is often that version. This post covers when a landing page is the better MVP, how to run one step by step, how it compares with working software, and the mistakes that make the results misleading.

When a Landing Page Is the Better MVP

A landing page is the better MVP when the main risk is market demand or willingness to pay, and the product could plausibly be built once demand is proven. In our experience that covers more first products than founders expect, since the open question is usually who will buy rather than how to build.

The test is to list the assumptions behind the business and ask which one would kill it if it were wrong. If the answer is "nobody will pay for this," a page can test it. If the answer is "we cannot get the data" or "the algorithm may not work," it cannot, and no amount of marketing copy will help.

A landing page also fits when the market is unclear. Running two or three pages with different promises or audiences shows which segment responds before any code commits you to one.

How to Run a Landing Page MVP Step by Step

Running a landing page MVP is a sequence of seven steps, from naming the riskiest assumption to deciding what to build. We follow them in this order because each step sets up what the next one measures.

1. Write the Single Assumption You Are Testing

Write one sentence such as "independent dental practices will pay a monthly fee to automate insurance follow-ups." A page can test one assumption cleanly, and several at once will blur the result.

Name the customer, the problem and the price range. If you cannot write the sentence, the idea is not ready for a test of any kind.

2. Describe the Outcome, Not the Feature List

Lead the page with the result the customer gets, in their words, then add two or three supporting points. Visitors decide in seconds, and a list of features invites them to compare rather than commit.

The common mistake is describing the product in so much detail that you are effectively designing it on the page. Keep enough ambiguity that the response measures interest in the promise, not in one interface.

3. Ask for a Real Commitment

The call to action should cost the visitor something, such as an email for early access, choosing a paid plan, booking a call or placing a pre-order. "Learn more" measures curiosity, not demand.

The stronger the commitment, the stronger the signal. A deposit or pre-order is the clearest evidence of willingness to pay, but if you take money, be ready to deliver, refund promptly or explain the delay.

For physical goods sold online, the FTC's mail, internet or telephone order rule requires a reasonable basis for stating or implying that you can ship within a certain time, and a prompt refund when a buyer does not agree to a delay, so check with counsel which rules apply to your offer.

4. Add a Pricing Step to Test Willingness to Pay

Buffer's founder Joel Gascoigne described exactly this. His first test was a two-page MVP whose aim was to check whether people would even consider using the app. He then added a pricing page between the two, so the extra click tested both the price, by detecting which plan people chose, and the strength of demand.

The same article reports that he built the first version over 7 weeks of evenings and weekends and had his first paying customer within 4 days of launching it. The page came first, and the software followed once the signal was clear.

5. Set Success Thresholds Before Launch

Decide in advance what result would justify building, what would justify a rewrite of the promise, and what would end the idea. Write the thresholds down before the first visitor arrives.

Without thresholds, every result looks encouraging. With them, the page produces a decision rather than an opinion.

6. Send the Right Visitors to the Page

A page with no visitors proves nothing, and the wrong visitors prove the wrong thing. Send traffic from the places your intended customers already gather, such as targeted ads, industry communities or direct outreach to a list of prospects.

Track each source separately. A high sign-up rate from friends and a low one from real prospects is a common pattern, and only the second number matters.

7. Talk to the People Who Respond

Numbers say how many people responded, and conversations say why. Email or call the people who signed up and ask what problem they hoped the product would solve and what they use today.

These conversations often change the product more than the conversion rate does. They also give you the first list of design partners for the version you build next.

Landing Page MVP Versus Working Software

A landing page MVP and a working-software MVP answer different questions, so the choice depends on which risk is largest. We use this comparison with founders to decide which to start with.

Many products need both in sequence. A page proves people want the promise, then a small working version proves the product keeps it.

Landing Page MVP Mistakes That Produce False Signals

The most damaging landing page mistakes produce results that look like validation but are not. We see these often:

• A weak call to action, so sign-ups measure curiosity rather than intent to buy.
• Traffic from friends, colleagues or broad audiences who will never be customers.
• No thresholds set in advance, so any result is read as success.
• Over-building the page with animations and detail until it becomes a design project.
• Ignoring the people who signed up instead of talking to them.
• Promising features or dates the team has no plan to deliver.

The last one matters for trust. Treat everyone who responds as a future customer, tell them honestly that the product is in development, and follow up when you have something to show.

When Working Software Is the Better MVP

Working software is the better MVP when the risk is technical, when value only shows up through use, or when buyers will not commit without trying the product. We would build first for products such as data integrations, workflow tools that must fit existing systems, or anything where the answer to "does it work?" is genuinely uncertain.

A landing page can still play a part here. It can recruit the first users for the build, test which audience responds best, or check pricing while engineering works on feasibility, so the two run in parallel rather than one replacing the other.

Even then, the build should stay small. Our founder's playbook on MVP development covers how we scope the smallest version that answers the real question, and deciding what to cut from your MVP scope explains how to keep that version honest. For other ways to test before building, see how to validate an MVP without building the full product.

Start With a Landing Page MVP When Demand Is the Question

A landing page MVP is the fastest, cheapest way to learn if people want a product before you build it. Name the single assumption, describe the outcome, ask for a real commitment, test price, set thresholds, send the right visitors and talk to the people who respond. When demand is the open question, we would start with a page, and when feasibility is, we would start with a small build.

If you are deciding between a page and a first build, the team at Better Software can help you choose the cheapest test that answers your question.

Frequently Asked Questions

What Is a Landing Page MVP?

A landing page MVP is a single web page that describes a product before it exists and measures how many visitors commit, for example by joining a waitlist or choosing a plan. We use it to test demand and willingness to pay before spending on software.

What Does MVP Mean for a Website?

For a website, an MVP is the simplest version that tests the main assumption behind it, often one landing page with a clear offer and a sign-up or purchase step. We add pages and features only after real visitors show the core offer works.

How Do I Create a MVP?

To create an MVP, we write the riskiest assumption, choose the cheapest test that could prove it wrong, and set success thresholds before launch. That test might be a landing page, a manual service or a small build, depending on if the risk is demand or feasibility.

What Is a Fake Door Test?

A fake door test shows users an option for a feature or product that does not exist yet and measures how many choose it. We pair it with an honest message explaining the product is in development, so the test gathers demand data without misleading people.

What Does MVP Mean in UX?

In UX, an MVP is the smallest experience that lets real users complete the core task and lets the team learn from their behavior. We focus it on one journey that works end to end, rather than a broad interface where nothing is finished.