Ship the Ugly Version

· 3 min read
shippingmvpexecution

Last year I built a system in 48 hours that a team had been “working on” for 6 months.

Same problem. Same goal. Different approach.

They were still designing the database schema. I had users.

The Pretty Trap

Engineers love to make things elegant:

  • Clean architecture
  • Perfect abstractions
  • Scalable from day one
  • “Done right”

Here’s the problem: You don’t know what “right” is until users touch it.

That perfect architecture you’re building? You’ll throw half of it away once you learn what actually matters.

My Process

  1. Make it work. Whatever it takes. Hardcoded values, copy-pasted code, no tests. Just function.

  2. Show it to someone. Watch them use it. Note where they get confused.

  3. Fix the confusion. Not with documentation. With simpler code.

  4. Repeat until they don’t get confused.

  5. Then make it pretty.

What Ugly Looks Like

The first version of my personal dashboard:

  • 800 lines in one file
  • Inline styles
  • No error handling
  • Hardcoded credentials
  • Comments like ”// TODO: fix this garbage”

It was embarrassing. It also:

  • Saved me 2 hours every day
  • Showed me what features actually mattered
  • Validated the idea before I invested real time

The Team’s Process

Meanwhile, the “proper” team:

  • 3 months on architecture diagrams
  • 2 weeks debating frameworks
  • Sprint planning, retros, standups
  • Zero users

They were building a cathedral for a god that might not exist.

The Confidence Gap

People think ugly code shows incompetence. The opposite is true.

Shipping ugly means:

  • You’re confident you can rewrite it
  • You prioritize learning over looking good
  • You understand that code is disposable

The engineers who obsess over clean code on day one? They’re afraid. Afraid they’ll be stuck with their mistakes. So they plan instead of building.

Good news: You can always rewrite. Bad code in production beats perfect code in your head.

When to Clean Up

Not immediately. Wait for:

  • Pain: Something’s actually hard to change
  • Users: Real people need reliability
  • Scale: You’re hitting real limits

Then refactor. But not before.

The Math

Ugly version: 48 hours → feedback → informed rebuild

Pretty version: 6 months → assumptions → potential waste

48 hours of real data beats 6 months of guessing.

The bottom line: Your job isn’t to write beautiful code. Your job is to solve problems. Beautiful code is a luxury. Working code is the requirement.

Ship ugly. Learn fast. Then make it good.

All articles