What You Should Know Before Building Your First MVP

Most first MVPs fail for the same reason: the team started building before they decided what the product was supposed to prove.

An MVP is not a smaller version of the finished product. It is a tool for answering one uncomfortable question with the least engineering possible. If you skip that framing, you end up with a half-built product that took three months and taught you almost nothing.

Here is what I'd want sorted before anyone opens a repo.

1. What question are you answering?

Write it down in one sentence.

Not "Will people use this?" That's too vague. Something closer to:

• Will a busy founder pay for weekly reporting that replaces a spreadsheet?
• Will a hiring manager upload CVs to an AI screener instead of reading them manually?
• Will a small clinic switch from WhatsApp bookings to a dedicated app?

If you can't name the question, you can't design the MVP. Everything else in the build is secondary to that one answer.

2. Who is the first user, specifically?

"SMEs" is not a user. "UK seed-stage SaaS founders who already run weekly ops reviews in Notion" is closer.

You need enough specificity that you could message five of them this week. If you can't list those people, you're not ready to build. You're still researching.

The first users also define what "good enough" means. A tool for technical founders can ship with a blunt UI. A tool for clinic staff cannot.

3. What are you deliberately not building?

This is the decision most founders avoid, and it's the one that keeps MVPs alive.

Make an explicit cut list:

• No admin panel in v1 if you can edit data yourself
• No native apps if a mobile web view covers the first use case
• No multi-tenant billing if you're onboarding the first ten customers by hand
• No fancy auth if magic links are enough

Every feature you add before you have proof is a bet that you'll still want it after the experiment. Most of those bets are wrong.

4. How will you know it worked?

Define success before the build, not after launch when you're tempted to move the goalposts.

Examples of usable success criteria:

• Five target users complete the core workflow without a call from you
• Three of them still use it two weeks later without prompting
• One of them pays, even a small amount

Vanity metrics (signups, page views, "interest") are almost useless for a first MVP. You're looking for behaviour change or willingness to pay.

5. Build vs buy vs skip

For each piece of the product, ask whether you need to own it.

Auth, payments, email, file storage, analytics: in almost every early product, you should buy these. Building them yourself burns time that should go into the part of the product that is actually unique.

The same applies to AI. If your MVP's value is "an AI that does X", then the model call and the workflow around it are the product. The surrounding CRUD is not. Don't spend the first month on the CRUD.

6. Who owns the technical decisions?

Even if you're non-technical, someone has to decide:

• Where the data lives
• How users authenticate
• What happens when the AI is wrong
• How you'll change the product after the first ten users

If that someone is a freelancer rotating every few weeks, you will rebuild more than you expect. Continuity matters more at MVP stage than most founders realise, because the product will change shape quickly and someone has to remember why the previous choices were made.

7. How messy are you willing to let it be?

A good MVP is slightly embarrassing. If it looks polished and complete, you probably overbuilt.

That doesn't mean ship broken software. It means ship the smallest coherent path through the problem, with clear edges, and treat everything outside that path as out of scope until the experiment says otherwise.

A simple pre-build checklist

Before writing code, you should be able to answer yes to all of these:

1. I can state the question this MVP answers in one sentence
2. I can name five real people in the target group
3. I have a written list of what we are not building
4. I know what success looks like in behaviour, not vanity metrics
5. I've decided what we'll buy instead of build
6. Someone is accountable for the technical decisions after launch
7. The first version can be ugly as long as the core workflow works

If any of those are fuzzy, pause. Clarifying them is cheaper than coding the wrong thing for six weeks.

The point

Your first MVP is not a miniature company. It's an experiment with a product-shaped interface. The founders who move fastest are usually the ones who were ruthless about scope before the first commit, not the ones who started coding earliest.

Get the question right. Cut hard. Measure behaviour. Then build only what that experiment requires.