Building the Product

Should we ship an ugly, half-working version now or wait until it feels good enough to be proud of?

A starting point

Ship the ugly version, but be honest about which kind of ugly it is. As a starting point: rough visual design and missing edge cases are fine to ship, because users forgive a plain UI, but a core flow that breaks or loses their data is not 'ugly', it is broken and it burns trust you cannot easily rebuild. The founder pride you should actually protect is 'this solved my problem', not 'this looks polished'.

Go deeper

Hand-picked from around the web, each with a note on why it earns your time.

2 resources 2 link-checked

Read

✍️ Essay
✓ Link checked Free Beginner

Why we picked it This is the fullest, most honest version of the Reid Hoffman line you have heard quoted ("if you're not embarrassed by the first version, you launched too late"), written out as an actual argument by Eric Ries, the person who built the Lean Startup idea. It is a starting point, not a rule: Ries's real claim is that quality lives in your customer's eyes, not yours, so waiting to feel proud can just mean polishing things nobody asked for. Read it before you spend another month making the ugly version prettier in private.

The Entrepreneur's Greatest Asset: Embarrassment

From Next Big Idea Club by Eric Ries ~6 min read

  • No matter how long you wait, you will be embarrassed by v1, so shipping later mostly costs you the feedback that tells you what to actually fix.
  • "Good enough" is judged by customers, not the team, and the two often disagree (Ries's IMVU users loved a feature the team was ashamed of).
  • The point of shipping early is to learn which rough edges matter and which do not, before you invest in polish.
Open nextbigideaclub.com →
📄 Article
✓ Link checked Free Beginner

Why we picked it "Ship ugly" and "wait until it's good" are not the only two options, and this piece gives you the vocabulary to tell them apart: minimum viable (does it work at all) versus minimum lovable (does anyone actually want to keep using it). It is practical about which rough edges are acceptable at the start and which quietly kill you, so you cut the right corners instead of every corner. Use it as a checklist for what "half-working" can and cannot include.

MLP vs MVP: Which Should You Build First (and Why)?

From Eleken by Eleken ~8 min read

  • A viable product can be rough as long as the core job it does works reliably; a lovable one adds just enough care that early users come back and tell others.
  • Cut polish and breadth early, but do not cut the one thing your product exists to do well, that is the edge you cannot ship broken.
  • The real target behind both is product-market fit, so choose the leaner or the more polished path based on how crowded your market is and how high your users' expectations already are.
Open eleken.co →

People also ask

How do I decide what to build next? Prioritize outcomes, not output, and use a simple scoring frame like RICE, Reach x Impact x Confidence, divided by Effort, to compare ideas honestl... Intermediate 2 resources → How often should an early-stage startup ship? Ship weekly, at least, cadence is a competitive advantage because faster loops mean faster learning. You haven't really started until you launch, a... Beginner 2 resources → How do I build a roadmap without over-planning? Work in short fixed cycles with variable scope, Basecamp's Shape Up runs on six-week bets, not a rigid multi-quarter Gantt chart. Make a few bets y... Intermediate 2 resources → How do I keep talking to users while I'm heads-down building? Make discovery continuous, not a one-time phase: interview a customer or two every single week, even in a build sprint. Teresa Torres's opportunity... Intermediate 2 resources → How do product teams keep a consistent shipping rhythm as they grow? Separate your planning cadence from your execution cadence and lean on async updates instead of endless meetings. A predictable operating rhythm, w... Advanced 2 resources → How do I say no to feature requests without losing customers? Anchor every 'no' to the outcome you're chasing and the customers you're building for, most requests are solutions in disguise, so dig for the unde... Intermediate 3 resources →