Building
Ship the ugly version.
By Muhammad UmarMay 31, 20256 min readIssue #4
The version you are embarrassed by is the only one that teaches you anything.
I spent most of a week making a settings page beautiful. Spacing, empty states, a small animation I was quietly proud of. Then I shipped it and watched what people actually did.
Almost nobody opened it.
That week cost me nothing in code and everything in learning. I had polished a room no one walked into. The feature people did want was sitting in a list, unbuilt, because it looked messy in my head.
Polish is a way of hiding
When you build alone, polish feels like progress. It has all the signals of work: you are typing, files are changing, the thing looks better at the end of the day.
But polish is safe. Nobody rejects a rounded corner. Shipping is not safe. Shipping invites a verdict.
So the perfectionism I used to call craftsmanship was mostly avoidance in a nicer outfit.
What ugly actually means
Ugly does not mean broken. It does not mean careless. I still care about the things that are expensive to fix later.
Ugly means: the smallest honest version of the idea, in front of a real person, this week.
- It does one thing, and that one thing works.
- It has no settings, no themes, no empty-state illustrations.
- It looks plain, and it says plainly what it does.
- It is easy to delete if the answer comes back no.
The last one matters most. Every hour of polish makes a feature harder to kill, because now you are attached to it. Cheap things are easy to be honest about.
The ladder of cheapness
Ugly is not one thing. It is a ladder, and most people jump straight to the top rung because the lower ones do not feel like building.
Each rung costs more than the one below it and buys you a more trustworthy answer. The skill is knowing how far up you actually need to climb before you learn what you came to learn.
| Rung | What it costs | What it tells you |
|---|---|---|
| A message to three people describing the thing | An hour | Whether the problem is real enough to reply about |
| A single page describing it, with a way to say yes | An afternoon | Whether anyone will take an action, not just agree |
| You doing the work by hand, invisibly | A week of tedium | Whether the output is worth anything once it exists |
| One hard-coded path through the real thing | A few days | Whether people use it when it is genuinely available |
| The built version | Weeks | How it behaves at volume, over time, with real mess |
The third rung is the one people skip, and it is usually the most informative. Doing the work by hand tells you what the automation would actually have to handle: every exception, every judgment call, every place where the rule you assumed existed turns out not to. You cannot learn that from a specification, because the specification is a description of what someone believes happens.
It is also the rung with the least ego in it. Nobody is proud of a spreadsheet. That is precisely why it stays easy to throw away.
Why polish makes you dishonest
The argument above is about cost. There is a second argument, and it is the one that actually changed how I work: polish does not just make a feature expensive to kill, it makes you a worse judge of whether it should live.
The mechanism is ordinary. Effort creates attachment, attachment creates a preferred answer, and once you have a preferred answer you stop asking neutral questions. You start asking whether anyone used it yet. You start finding reasons the low numbers are early rather than final. None of this is dishonesty in the ordinary sense. It is what everybody does when they have paid for something.
The purpose of the ugly version is not speed. It is to keep you cheap enough to stay honest.
Which reframes the whole exercise. Shipping early is usually sold as a way to move quickly. That is a side effect. The real function is that it protects your judgment from your own investment, and judgment is the thing you cannot buy back later.
The rule I use now
Before I build anything, I ask one question: what is the fastest version of this that could still get a real reaction?
Sometimes the answer is not code at all. A message to three users. A hand-written spreadsheet doing what the automation would do. A single page describing the thing, with a way to say yes.
You cannot think your way to a real answer. You can only ship your way there.
If it gets a reaction, I build it properly. Real error handling, real tests, real design. That work is worth doing, after someone has told you it is worth doing.
Reading the reaction
All of this rests on being able to tell a real reaction from a polite one, and that is harder than it sounds, because the polite reaction is designed to be indistinguishable.
The rule I settled on: count actions, not opinions. An opinion costs nothing to give and people give them generously, particularly to someone who has clearly worked on something. An action costs the person something: time, money, attention, a small amount of reputation. That cost is the entire signal.
| What you get back | Worth | Because |
|---|---|---|
| “This looks great” | Nothing | It is what people say. It survives being wrong. |
| “I would definitely use this” | Nothing | A prediction about a future self, made to be kind. |
| A feature request | Something | They imagined using it long enough to find a gap. |
| They used it once | Something | They spent attention, though novelty explains a lot of first uses. |
| They used it again, unprompted | A great deal | Novelty is gone. Something brought them back. |
| They complained it was broken | A great deal | You cannot be annoyed about a thing you do not need. |
| They paid | The most | The only signal that cannot be produced by politeness. |
The complaint row surprises people. An angry message about a bug is one of the better outcomes available to you. It means the thing sat on the path between someone and something they wanted. Silence is the outcome to fear, and silence is what a beautiful, unused settings page produces.
This is also why you should decide what would count as a reaction before you ship, and write it down. Deciding afterwards means grading your own work with the answers in front of you, and everyone passes that test.
When this is the wrong advice
Ugly works because it is cheap to delete. So the rule breaks in exactly the places where nothing can be deleted.
When the mistake is expensive to reverse. A rough interface can be replaced next week. A data model, an auth boundary, or anything touching money cannot. Those decisions harden the moment other things depend on them. Your stack is not the bottleneck makes the same distinction from the other direction. Ugly belongs on the surface, never in the foundations.
When you only get one look. Shipping ugly assumes you can iterate in front of the same person twice. Some audiences do not give you that. A buyer running a formal evaluation forms one judgment and files it. There, the rough version teaches you nothing. It just loses.
When being wrong hurts someone. Anything handling health, safety, or someone else’s money has a floor that “smallest honest version” sits below. The right move there is a smaller scope, not a rougher build. Fewer cases handled properly beats every case handled roughly.
The common thread: ugly buys information by trading away polish, and that trade is good whenever the polish is recoverable and the information is not. Reverse those two and you should reverse the advice.
The takeaway
Beautiful and unused is worse than plain and needed. Ship the ugly version, learn the truth, then earn the right to make it beautiful, and know which parts of the system were never eligible for the ugly version in the first place.