Why you should launch a small v1 instead of a perfect product

You should launch a small v1 because only real users can tell you what to build next, and every week spent polishing in private is a week of guessing. A perfect product usually isn’t perfect for anyone, because it was shaped by your assumptions instead of their behaviour. Ship the smallest version that solves one problem well, then improve it with what you learn.

This is an opinion piece, so I’ll be clear about where I stand: I believe “not ready yet” is the most common reason good side projects die. Not bad ideas, not competition. Just a launch date that keeps moving.

Perfect is a guess with extra steps

When you build without users, every decision is a prediction. Which feature matters most, how the onboarding should flow, what the pricing page should say. Each one feels reasonable. Stack twenty of them together and you have a product built entirely on guesses, with nobody to check them against.

Eric Ries, in his work on the lean startup, defined the minimum viable product as the version of a new product “which allows a team to collect the maximum amount of validated learning about customers with the least effort.” I like that definition because it isn’t about being cheap or rushed. It’s about learning. The v1 is not the product. It’s the instrument you use to find out what the product should be.

Embarrassment is part of the deal

Reid Hoffman, the LinkedIn co-founder, has a well-known line: “If you’re not embarrassed by the first version of your product, you’ve launched too late.” I don’t read it as permission to ship something broken. I read it as a warning that the feeling of “almost ready” never goes away on its own. If you wait until you’re proud of everything, you’ll wait forever, and the market will move while you do.

There is a difference, though, between rough and careless. A small v1 can have one feature, a plain design, and manual work behind the scenes. It cannot lose people’s data, break their trust, or promise something it doesn’t do. Rough edges are fine. Broken promises are not.

Why this matters more on the side

When building is your full-time job, a long build is expensive. When it’s a side project, a long build is often fatal. Motivation fades. Life gets busy. The project that felt exciting in month one feels like homework in month five.

A small launch gives you something a long build can’t: an outside reason to keep going. A real person using what you made, even one, creates momentum that private polishing never does. I wrote about protecting your time and energy when you build on the side, so I won’t repeat that here. The short version is that a small scope is what makes the time you have enough.

My “good enough to launch” checklist

This is what I’d check before calling a v1 ready. If every box is ticked, I think it’s time to ship, even if your list of “one more thing” is still long.

1. It solves one problem from start to finish. A single user can go from “I have this problem” to “this helped” without you explaining it on a call.
2. You can say who it’s for in one sentence. If you can’t, the product will try to please everyone and help nobody.
3. The core path works every time. Not every feature, just the main one. Test it yourself several times on a phone and a laptop.
4. It’s safe. No exposed personal data, no payments that can go wrong, no permissions it doesn’t need.
5. There is a way to hear back. An email address, a short feedback form, or a reply-to that a real person reads.
6. You know what you’re measuring. Pick one or two signals in advance, like “people come back a second time” or “someone pays.” Otherwise you’ll read whatever you want into the numbers.
7. Things you can do by hand stay manual. If onboarding, reporting or support can be done manually for the first users, do that. Automate later, once you know what’s worth automating.
8. The cut list is written down. Every feature you decided not to build goes on a list. This makes it easier to let go, because you’re postponing, not deleting.

Notice what’s not on the list: a logo you love, a full settings page, dark mode, an admin panel, a pricing page with three tiers. All of that can come after real people have told you it matters.

What happens after launch

The first week after a small launch is usually quiet, and that’s normal. The work now is to talk to whoever did show up, watch where they get stuck, and fix the one thing that would help most. Then ship again.

I think of it as a loop more than a launch. Small version, real feedback, one improvement, repeat. It’s less exciting than a big reveal, but it’s the version that actually gets finished.

Sources

• Eric Ries: Minimum Viable Product, a guide (2009)
• Reid Hoffman quote and its earliest documented source (Rowan Simpson)