Launch an MVP fast (without over-engineering it)

An MVP (minimum viable product) is not an ugly version of your final product. It's the smallest thing that lets you learn whether people actually want it. Its job isn't to impress — it's to answer a question as fast as possible. Here's how to ship one in a weekend.

Cut your MVP scope down to ONE function

The number one reason MVPs drag on for six months: too many features. Ask yourself: “what is the single thing my product must do to prove its value?” Everything else (accounts, dashboard, settings, automated payments) can wait. If you're torn between two functions, your MVP is already too big.

Pick the right type of MVP

You don't have to write code. Three approaches, from fastest to most built-out:

• Concierge MVP — you deliver the service by hand, manually, for your first customers. Perfect for validating a service before automating it.
• Wizard of Oz — the user believes they're interacting with an automated product, but it's you behind the curtain. Ideal for testing the experience without building the engine.
• No-code / single-function MVP — a no-code tool, a Google Sheet, a bot, or a small script that does the essential part. Enough for 90% of first tests.

Define your MVP's learning metric

Before launching, write down the question the MVP must answer and the number that settles it. Examples:

• “Do people complete the key action?” → completion rate > 40%.
• “Do they come back?” → X% of users active on day 7.
• “Would they pay?” → at least N pre-orders.

Without that metric, you'll confuse “it's launched” with “it works”.

Distribute your MVP (otherwise it doesn't exist)

An MVP with no users teaches you nothing. Plan where you'll show it before you finish it: relevant communities and Discord servers, specialised groups, your network, Product Hunt, or a small ad budget. Distribution is part of the MVP, not an afterthought.

The over-engineering trap in an MVP

Every hour spent polishing code nobody uses yet is an hour stolen from learning. Until you have proof that people want the product, treat the code as disposable. Scalability, technical cleanliness and perfect design are rich people's problems — you'll solve them when you have users.

A realistic 48-hour MVP schedule

• Friday evening: write down the hypothesis, the user profile and the threshold that validates the test. Delete every function that doesn't serve that measurement.
• Saturday morning: sketch the full journey on paper, from arrival to the expected outcome. Cap it at five screens or steps.
• Saturday afternoon: build the main flow with simple data. Plan an honest message for the cases you'll handle manually.
• Sunday morning: have three people run through the journey without guiding them. Fix only what stops them reaching the value.
• Sunday afternoon: open the test to a small targeted group, observe, and schedule the follow-up interviews.

Worked example: a specialised quote generator

To test a quote generator aimed at wedding photographers, there's no need to build account management, a template library and invoicing. A first version can be a form that collects the wedding details; the founder then produces the quote from a template and sends it back within ten minutes. The customer judges the result, not the automation hidden behind it.

The experiment measures three things: do photographers fill in the form, do they use the quote they receive, and would they pay to save that time every week? After ten uses, the repetitive steps you observed tell you exactly what to automate first.

Deciding what to do after the MVP test

Separate value-proposition problems from usability problems. If nobody starts the journey, the promise or the targeting is probably weak. If many start but drop off at the same point, fix the journey. If users finish but don't come back, check that the problem occurs often enough. A metric alone doesn't give you the cause: back it up with five interviews focused on facts, especially what the person was doing before and after the test.

If you're not slightly embarrassed by your MVP at launch, you launched it too late.

Above all: only build an MVP if the demand is already there. Start by validating the idea, then test it with a landing page before you write a single line of code.