Building in Public: What Six Months of Side Projects Taught Me
Six months ago I committed to shipping real products, not just building things privately. Here's what actually happened.
What I Built
Four apps made it to production:
- Portfolio Rebalancer — multi-user investment portfolio tooling, freely given to the FIRE community as a small repayment for years of invaluable information they've shared openly
- Incase of Badness — encrypted emergency info for families
- My Countdown — live ticking timer and countdown tracker
- Habit Tracker — hierarchical habit tracking with flexible frequencies
None of them have massive user bases yet. All of them are being used by real people — and for me, that's the signal that matters.
The Customer of 1
Every one of these apps started the same way: I personally wanted it to exist and couldn't find anything that did it right.
That's the only filter I used. Not market research, not customer discovery interviews, not TAM analysis. Just: do I genuinely want this? Not "it would be kinda cool" want it — actually want it, enough to use it every day.
My working theory is that if I want something badly enough, I can't imagine I'm the only one. The specificity of what you want is usually the product's edge. Someone who really wanted a rebalancing tool built it the way a real rebalancer would use it — because they are one.
Customer of 1. Ship it. See who shows up.
The Launch Fallacy
I used to believe that a good product would attract users if you just shipped it. This is completely wrong.
Every launch is invisible unless you make it visible. The projects that got traction got it because I posted about them, emailed people I knew, and asked directly for feedback. The ones I shipped quietly stayed quiet.
The Constraint That Helped Most
I started with a three-month rule: if I couldn't ship an MVP in three months, the scope was wrong. It worked, but barely — three months is long enough to drift, gold-plate, and second-guess yourself into a worse product.
The honest truth is I stuck with three months because that's what the time allowed. Building nights and weekends, that was the realistic ceiling.
AI changed the calculus entirely. I can now set a two-week rule and actually hit it. Not because the apps are simpler — they're not — but because the gap between idea and working code has collapsed. Planning, scaffolding, debugging, refactoring: what used to take days now takes hours. The constraint isn't talent or time anymore. It's clarity of thought.
The Habit Tracker was still the hardest. I had a roadmap with 14 features. I shipped with 4. Three months in, the same four features are the ones people use.
What Building in Public Actually Does
It creates accountability, but more importantly it creates evidence. When someone asks what you can build, you have links, not descriptions.
It also forces you to articulate why something matters. Writing the launch post for Portfolio Rebalancer clarified the product positioning more than any internal doc I'd written.
What I'd Do Differently
- Pick one channel and go deep — I spread thin across Twitter, IndieHackers, and Reddit. Pick one.
- Build adjacent products — each new app should benefit from the audience of the last one.
- Tell the origin story — why you personally needed this is the most compelling thing you can say. Most people skip it.
The throughline: shipping is a skill. You get better at it by doing it.