How to Build Your First MVP

The phrase "minimum viable product" is misunderstood in a specific and costly way. Teams hear "minimum" and build a cut-down version of everything they imagined — a thinner version of a big product, with every feature half-present.

A better definition: an MVP is the smallest thing you can put in front of a real person that delivers a real outcome, and that teaches you something you cannot learn by asking. The emphasis is on the outcome and on the learning, not on the code.

Start from the outcome, not the feature list

Write one sentence: "After using this, [specific person] has [specific outcome] that they did not have before."

For example: "After using this, a fest sponsorship lead knows which twelve companies were contacted, by whom, with what promised, without opening WhatsApp."

Everything that does not directly produce that outcome is out of scope for version one. Accounts, dashboards, settings pages, dark mode, an admin panel, a landing page with animations — all out. Not "later in the sprint": out.

This single sentence is the strongest scoping tool available, because it converts arguments about features into a question with an answer: does this move the person closer to the outcome?

Many good MVPs contain no product at all

Student teams reach for code first because that is the skill they are proud of. But several MVP types learn faster and cost less.

The concierge. You deliver the outcome manually. The user asks; you do the work by hand and send the result. If you plan to build a resume-feedback product, review five resumes yourself and send the feedback in a document. You will learn what "good feedback" means far faster than any interface would teach you.

The Wizard of Oz. The user sees what looks like a product; a human is behind it. A form on a page, a person reading submissions and replying within an hour. Useful when the interaction pattern matters but the automation does not exist yet.

The single-flow build. One screen, one action, one result. No login, no navigation, no settings. Hard-code whatever can be hard-coded.

The spreadsheet. A shared sheet with a clear structure and a person who maintains it. Unfashionable, and repeatedly effective for coordination problems.

The document. For content, research or advisory products, the first version is often just a well-made document delivered on a schedule.

Choose the lightest form that can still produce the outcome. You can always automate a process that people already value; you cannot automate your way into value that is not there.

Scope it to weeks, not months

A first MVP that takes a semester is not an MVP. Use a hard time limit — two to four weeks of part-time work — and cut scope to fit the limit rather than extending the limit to fit the scope.

Practical rules that keep scope honest:

• One user type. Not students and colleges and recruiters. One.
• One core action. The thing the outcome depends on.
• Manual over automatic. If a human can do it for ten users, do not build it yet.
• Existing tools over new ones. Forms, sheets, chat groups, no-code builders and off-the-shelf auth exist; use them.
• No admin interface. You are the admin, and you have database access.
• Ugly is acceptable. Confusing is not. Spend your design effort on clarity, not polish.

If you cannot fit the outcome into the time box, the outcome is too big. Narrow the person or narrow the promise.

Get it in front of people the day it works

An MVP that no one uses has taught you nothing, regardless of how well it is built. Line up your first five users before you finish building — ideally people you already interviewed, who described the problem in their own words.

Onboard them personally. Sit with them, or share a screen. Watch them use it without instructions and without helping them. Where they hesitate, note it and stay silent. The hesitations are the product feedback; what they say afterwards is commentary.

Measure behaviour, not applause

Decide what you will measure before launch, and keep the list short. For a first MVP, four numbers are usually enough:

• Activation: how many people who started actually reached the outcome once?
• Repeat use: how many came back and did it again without being asked?
• Time to outcome: how long from arriving to getting the result?
• Drop-off point: where exactly do people stop?

Add one qualitative signal: what did users do immediately after getting the outcome? Did they share it, ask for more, or disappear?

Vanity metrics to ignore at this stage: page views, signups without use, social media reactions, and the number of features shipped.

Read the result honestly

Three outcomes are possible after a few weeks of real use.

People use it repeatedly without prompting. Rare and valuable. Now the questions become: can more people be reached, and can the manual parts be automated without losing quality?

People use it once and stop. The most common outcome. Usually the outcome was real but shallow, or the effort of using it exceeded the value delivered. Look at your drop-off point and your time-to-outcome before changing anything else.

People do not use it at all. Either you built for the wrong person, or the problem is not painful enough, or the outcome you promised is not the outcome they wanted. Return to conversations; do not add features.

Adding features is the standard response to weak usage and it is almost always the wrong one. A product that nobody uses does not become useful with more surface area.

What "viable" really means

Viable does not mean complete. It means the user gets genuine value without you standing next to them explaining it, and it means the value is real enough that they would notice if it disappeared.

That is a low bar in scope and a high bar in honesty. Most first attempts clear the scope bar and fail the honesty one.

From MVP to a business question

Once something works for a handful of people, the question changes shape. It stops being "does this help anyone?" and becomes "can this reach enough people, deliver value repeatedly, and sustain itself?"

That is a question about the model around the product — who pays, how much, how you reach people, what it costs you to serve each one. A working MVP with no answer to those questions is a good project. With an answer, it starts to be a business.