> ## Content Index > Fetch the complete content index at: https://riot.ghost-themes.apps.codememory.com/llms.txt > Use this file to discover other available public pages before exploring further. # Ship the ugly version: lessons from 31 side projects - URL: https://riot.ghost-themes.apps.codememory.com/ship-the-ugly-version-lessons-from-31-side-projects/ - Published: 2026-08-18T07:00:00.000Z - Updated: 2026-08-18T07:00:00.000Z - Description: Thirty-one side projects, nine that made money. What the winners had in common: they shipped before they were ready. - Author: Jonah Park - Tags: Creativity, Growth, #Import 2026-09-30 04:45 I have started thirty-one side projects in the last eight years. Nine of them made money. Three of them paid my rent for a while. One of them became this newsletter. And almost every one that worked had the same thing in common: I shipped it before it was ready. This issue is about the ugly first version, why it matters so much, and how to make yourself put it out into the world. ![A side project on day one: a wall of sticky notes and too much optimism.](https://riot.ghost-themes.apps.codememory.com/content/images/2026/09/ship-post-its-1.jpg) A side project on day one: a wall of sticky notes and too much optimism. ## The graveyard of perfect projects For every project I shipped, there are two I did not. They live in a folder on my laptop called "later", and they are, in their unfinished state, perfect. Perfect logos. Perfect plans. Perfect landing pages that nobody has ever seen. They are also worth nothing. An idea that stays in your head can never disappoint you, which is exactly why it can never help you either. > A finished bad thing teaches you more than an unfinished perfect one. > > **Jonah Park** ## What "ugly" actually means Shipping ugly does not mean shipping broken. It means shipping the smallest version that does the main job, and leaving out everything else. A course with three lessons instead of twelve. An app with one feature instead of ten. A shop with one product instead of a catalogue. The first version of this newsletter was a plain email with no logo, no design and a subject line I am still embarrassed by. It had forty-one readers. It was enough to learn what people actually wanted. ![](https://riot.ghost-themes.apps.codememory.com/content/images/2026/09/ship-sketch-1.jpg) ![](https://riot.ghost-themes.apps.codememory.com/content/images/2026/09/ship-cardboard-1.jpg) ![](https://riot.ghost-themes.apps.codememory.com/content/images/2026/09/ship-laptop-1.jpg) Paper, cardboard and a late night: most first versions look like this. ## The one-weekend rule My rule now is simple. If I cannot build a first version in one weekend, the idea is too big. I cut it in half, then in half again, until it fits. What is left is usually the only part that mattered anyway. 🚀 Ask yourself: what is the one thing this project must do? Build only that. Everything else is version two, and you might never need version two. ## Show it to five people Once the ugly version exists, show it to five people who might actually use it. Not friends who will be nice. People with the problem you are trying to solve. Watch what they do, not what they say. If they ask when they can pay for it, you have something. If they say "that's cool" and change the subject, you have learned something too, and it only cost you a weekend. ![The best feedback comes from watching people use the thing, not asking them about it.](https://riot.ghost-themes.apps.codememory.com/content/images/2026/09/ship-team-1.jpg) The best feedback comes from watching people use the thing, not asking them about it. ## The feelings nobody talks about Shipping something ugly feels terrible. You will want to explain it, apologise for it, add a note saying "this is just a beta". Resist most of that. People are far less critical than the voice in your head, and most of them will not notice the things you are worried about. The feeling fades with practice. By the tenth project, sharing something rough feels normal. By the twentieth, it feels like the only sensible way to work. ## Version two, if you need it When an ugly first version does find its people, the temptation is to rebuild everything properly. Resist that too. Improve it one piece at a time, in the order your users ask for, and keep shipping small changes every week. The newsletter is a good example. Version one was a plain email. Version two added a simple website. Version three added paid memberships. Each step happened only after readers asked for it, and each one took a weekend or two, not months. ### The projects that failed It would be dishonest to write this without mentioning the other twenty-two. Most of them failed for the same reason: nobody had the problem I was solving. A few failed because I lost interest. Two failed because I spent months building before showing anyone, which is exactly the mistake this issue is about. None of those failures were expensive, because none of them took long. That is the hidden benefit of shipping small: when something does not work, you lose a weekend, not a year. You can afford to try again, and again, until something does. ### A useful list Keep a simple list of every project you ship, with the date, what it was and what you learned. Mine has thirty-one lines. Reading it back is the best reminder I know that the only real failure is not shipping at all. ## What the nine winners had in common Looking back at the nine projects that made money, every one of them was small at launch, solved one clear problem for a specific person, and got better because of feedback, not planning. None of them were my best ideas on paper. They were the ideas I actually finished. So here is your homework: pick the smallest idea in your "later" folder. Give it one weekend. Ship the ugly version on Monday and tell five people. Then reply and tell me how it went. ![Launch day for a project nobody has heard of yet.](https://riot.ghost-themes.apps.codememory.com/content/images/2026/09/ship-rocket-1.jpg) Launch day for a project nobody has heard of yet.