The one thing

Build the smallest version a real person can actually use, in weeks not months, and put it in front of them fast.

Start here

The goal is something a real person can use and react to, quickly. Perfect can wait. What that first version looks like depends on your idea. If your idea is physical, the first version is a single sample or a pre-order. If it is a service, it is you doing the work by hand for one customer. If it is software, it is the one screen or step that solves the core problem, and nothing else around it.

You will ship something that makes you a little embarrassed. That is correct, and you should expect it. It never feels good enough, and waiting until it does is how a year disappears. A product you are proud of on day one is a product you waited far too long to launch. Build it rough, put it in front of a real person, and watch what breaks. One real person using your thing for ten minutes teaches you more than a month of quiet polishing alone at your desk, because you have been guessing what matters and they will show you.

The trap to avoid is building for the version of the customer in your head, who is patient and forgiving and reads every instruction. Real people are busy, distracted, and quick to give up. Build for them. If the one core thing is not obvious and quick, nothing else you add will save it.

What to do

Take your smallest offer from the last stage and build only that. Set yourself a short deadline, measured in weeks, and hold it. A deadline is what stops "one more feature" from eating your month.
Put it in front of one real person and watch them use it. Do not explain. Do not defend. Do not hover and narrate. Watch where they hesitate, get confused, or give up. Their confusion is the most useful thing you will get all week.
Fix the one thing that broke the worst. Just the worst one. Then put it in front of the next person and do it again.
Resist adding new features while the core one is still confusing. A second feature on top of a broken first feature is two problems, not a better product.

A worked example

Say your offer is the tutor payment-chasing service. Your first version is not an app. It is a shared sheet and a set of messages, and you run it by hand. You tell one tutor: send me your unpaid invoices, I will chase them for you this month. She sends you a photo of a messy notebook. Right there, before you have built anything, you have learned that getting the data out of her head is the hard part. Sending the reminders was never the difficult bit.

So your rough first version becomes a simple form she fills in with student name, amount, and due date. You watch her use it. She fills in the name and the amount but skips the date every time, because she does not track dates, she tracks "the start of the month." That is the kind of thing you could never have guessed from your desk. You change the date field to a simple dropdown of "start, middle, end of month" and suddenly she can use it in seconds. One real person, one real session, and your product got meaningfully better. If your idea were software instead, the same rule holds: build the one screen that does the core job, watch one person use it, and fix what actually trips them up rather than what you imagined might.

The fear, named

The fear is that people will judge you for something rough and unfinished, so you keep polishing to protect yourself. Name what that really is. Polishing in private feels like progress but it is often just hiding, because a thing nobody has seen cannot be rejected and cannot be wrong. The founders who win make peace with launching before they are ready, and they let real use tell them what to fix instead of their own pride. The embarrassment of a rough launch fades in a day. The cost of a year spent perfecting the wrong thing does not.

Your move this week

Get your rough first version in front of one real person and watch them use it, without explaining or defending. Write down the first thing that broke or confused them. Fix that one thing. That is the whole job this week.

You are ready when

A real person has used your first version, you watched what broke, and you fixed the worst of it and showed the next person. You are now learning from reality instead of guessing. As soon as you have a few people and a few promises to keep, the load starts to spill out of your head, so the next chapter sets up the simple systems that keep it all from falling through.

Build Your First Version