What Building 2 Products in 3 Months Taught Me About Shipping Fast

Disclosure: I work on Opennomos.

Three months ago, I set out to build two products simultaneously: a photo cleaner app and an MVP development framework. I'd read all the indie dev success stories and figured shipping fast was just about writing code faster. I was wrong.

Here's what actually mattered.

1. The Real Bottleneck Isn't Coding — It's Decision Fatigue

On any given day building a product, you make hundreds of micro-decisions:

• Should this button be blue or green?
• Do I need pagination or infinite scroll?
• Should I fix this edge case now or ship first?

Each decision burns mental energy. By 2 PM, I couldn't make good choices anymore. The solution wasn't "be more decisive" — it was eliminating decisions entirely.

I started using a simple rule: if a decision doesn't affect whether the core feature works, flip a coin and move on. Ship the ugly version. You can fix it when users complain (and they will).

2. Your First 10 Users Don't Care About Polish

I spent two weeks perfecting the onboarding flow for my photo cleaner. Beautiful animations, contextual tooltips, the works. When I finally launched and watched real users interact with it, they skipped past every single tutorial and just started tapping buttons randomly.

The takeaway: your first users are explorers, not readers. They learn by doing. A polished onboarding flow matters when you have 10,000 users, not 10. Ship the bare minimum and watch where they get stuck — that's your real roadmap.

3. Audience > Product (Every Single Time)

This was the hardest lesson. I built a solid photo cleaner and showed it to other developers on Twitter. Feedback was lukewarm — "nice UI," "clean code," generic praise. Then I showed the exact same product to people who regularly take 500+ photos at events. The reaction was completely different: "Wait, this solves my actual problem."

Same product, different audience, 10x the enthusiasm. Before you build anything, ask: Who specifically has this problem right now, and how do I reach them?

What I'd Do Differently

Looking back at 3 months and 2 products, here's my revised playbook:

1. Week 1: Talk to 5 potential users before writing a single line of code
2. Week 2-3: Build the absolute minimum that solves exactly one problem
3. Week 4: Ship it to the 5 users from week 1, get brutal feedback
4. Month 2-3: Iterate based on what actual users say, not what you imagine

The indie dev path isn't about building faster — it's about learning faster. Every day you spend building features nobody asked for is a day you're not learning what they actually need.

---

What's the hardest lesson you've learned shipping a product? I'd love to hear it in the comments.