Every solo dev knows the voice. You're about to ship, and it whispers: "Just add dark mode. Just polish the onboarding. Just one more feature."
That voice killed two of my projects before I learned to ignore it.
The Trap Is Disguised as Professionalism
Here's what nobody tells you: perfectionism feels productive. You're coding. You're iterating. You're "improving the product." But you're not shipping, and if you're not shipping, you don't have a product — you have a hobby.
I spent three weeks building a custom settings UI for one of my apps when the default macOS preferences panel would have been fine. Three weeks. Zero users saw it. Zero users cared. I was solving imaginary problems for imaginary people.
My Ugly MVP Rule
Now I follow a brutal rule: if it works, ship it.
Not "if it looks good." Not "if it handles every edge case." If the core function works and it doesn't crash, it goes live.
When I built Monk Mode — a macOS focus tool that blocks distracting feeds — the first version looked rough. The UI had maybe two screens. No fancy animations. No custom theming. But it did the one thing it promised: it blocked your Twitter feed, your Reddit feed, your YouTube recommendations — without nuking the entire app.
People didn't care that it was ugly. They cared that it worked.
What "Ugly" Actually Teaches You
Shipping early forces you to confront reality. You learn:
- Which features people actually request (hint: rarely the ones you planned)
- Where users actually get stuck (never where you expected)
- Whether anyone wants this at all (the hardest lesson)
I've watched solo devs spend six months building something beautiful that nobody downloads. Meanwhile, ugly apps with clear value propositions rack up users because they exist.
The Compound Effect of Shipping Fast
Every week you don't ship is a week of zero feedback. Zero data. Zero learning.
When you ship ugly, you start a feedback loop:
- Week 1: Ship MVP, 10 people try it
- Week 2: Fix what actually breaks, 30 people try it
- Week 3: Add the ONE feature everyone asked for, 100 people try it
Compare that to:
- Weeks 1-8: Polish in isolation, 0 people try it
- Week 9: Ship "perfect" version, 10 people try it, half wanted something different
How I Decide What's "Good Enough"
My checklist before shipping anything:
- Does the core feature work?
- Does it crash on launch? (You'd be surprised)
- Would I be embarrassed if a stranger saw it?
- Can someone figure out what it does in 30 seconds?
If I check at least the first three, it ships. That fourth one is a nice-to-have.
The Permission You Need
If you're a solo dev sitting on something half-finished because it's "not ready" — it's ready. Ship it. Put it on Product Hunt. Post it in a Discord. Send the link to five people.
The worst thing that happens is nobody cares. And that's actually the best possible outcome, because now you know before you invested another month.
Your users will tell you what to build next. But only if you give them something to react to.
I'm building native macOS apps as a solo dev. If you're interested in focus tools or dev utilities, check out what I'm working on at mac.monk-mode.lifestyle.
Top comments (0)