Your First MVP

You've talked to customers. You've heard about their problems. Now you want to build. This is where most founders waste months and thousands of dollars building something nobody asked for.

Validation Narrows Choices

At the end of real customer validation, things should feel smaller, not bigger.

You should know:

• Who this is not for
• Which use cases matter
• Which features do not matter
• What they already pay for
• Why they switch (or don't)

If everything still feels possible, you have not validated anything. Go back and do more customer interviews.

Find the ONE Thing

Your interviews should reveal a core problem. Not five problems. Not a platform. One problem that is painful enough that someone will pay to make it go away.

Your MVP is not a list of features. It is the smallest possible thing that solves that one problem well enough to test whether people will actually use it and pay for it.

Your First Customers Do Not Need a Product

You do not need software to validate demand. You can:

• Do it manually
• Use email, Notion, spreadsheets, Slack, text messages
• Act as the product yourself

If someone will not accept the solution when it is manual and ugly, they are not a customer. They are an audience member.

The Concierge Test

Before you build anything, try doing the job yourself. Manually. For real customers.

If you're building a scheduling tool, be the scheduling tool. Email people, coordinate calendars, send reminders. Do it by hand for 10 customers.

You will learn more in one week of manual work than in three months of building. You'll discover edge cases, workflow problems, and whether people actually care enough to use this thing.

Do Not Hire a Contractor

Founders love to think they can shortcut the work by paying someone else to build it. This almost never works at the MVP stage.

Why:

• You don't know what to build yet. You're paying someone to build your guesses.
• Every change costs money and time. You need to iterate fast.
• Contractors build what you spec, not what you need. You don't know what you need yet.
• You'll spend more time managing the contractor than learning from customers.

Build the Ugliest Thing That Works

When you do build, build the minimum. Not the "minimum viable product" that looks like a real product. The actual minimum.

• No onboarding flow. Just a form.
• No dashboard. Just an email with results.
• No mobile app. Just a website that works on mobile.
• No payment integration. Just send them an invoice.

Every feature you add is a feature you have to maintain, explain, and potentially remove later. Start with less than you think is possible.

Speed Over Polish

Your MVP should take days or weeks, not months. If it's taking months, you're building too much.

The goal is to get something in front of real users as fast as possible so you can learn. Every day you spend building is a day you're not learning from customers.

How to Know If Your MVP Is Working

Your MVP is working if:

• People use it without you asking them to
• They come back without reminders
• They tell other people about it
• They ask when they can pay (or they already are)
• They complain when it breaks

Your MVP is not working if:

• You have to convince people to try it
• They try it once and disappear
• They say "this is cool" but don't use it
• They have no feedback because they haven't actually used it

When to Build More

You earn the right to build more features when:

1. You have users who actively use what you built
2. Those users are asking for specific improvements
3. You understand why they want those improvements
4. Adding the feature will help you retain or grow users

Until then, keep it small. The best founders resist the urge to build. They stay close to customers and let demand pull features out of them.