Why I'm Building in Public
The philosophy behind building openly — sharing the journey, the failures, and the wins. Why transparency is a superpower for indie makers.
The End of the Secret Builder
For most of my career, I followed the traditional playbook: build in stealth, perfect the product, then launch with a big bang. That approach has its merits — but it also has a fatal flaw. You're building in a vacuum.
Building in public flips the model entirely. Instead of hiding your work until it's "ready," you share the process — the messy middle, the wrong turns, the small wins. Every step becomes an opportunity for feedback, connection, and momentum.
What Changed My Mind
When I started working on Workout Lens, I kept it quiet. I wanted everything to be perfect before showing the world. Two years of development went by. Two years of building without a community, without user feedback, without the accountability that comes from public commitment.
The contrast with MintJane couldn't be starker. From day one, I started posting about the journey on X. Every milestone, every setback, every decision. The response was immediate — people started following along, offering suggestions, and becoming genuinely invested in the product.
The lesson was clear: the story matters as much as the product.
The Three Pillars of Building in Public
1. Radical Transparency
Share your numbers, your process, your mistakes. When I posted about a bug that caused Workout Lens to crash during a half-marathon test, the response was overwhelmingly positive. People don't expect perfection — they expect honesty.
2. Community as a Feature
When you build openly, your users become collaborators. Feature requests turn into conversations. Bug reports turn into relationships. The community around your product becomes its most powerful distribution channel.
3. Consistent Momentum
Silent projects die. When nobody knows you're building, motivation wanes. When you post every day about progress — even small progress — you create a streak that's hard to break. The accountability is real.
The Counter-Arguments (and Why They're Wrong)
"People will steal your idea." — Ideas are cheap. Execution is everything. If your only moat is secrecy, you don't have a moat.
"It's unprofessional." — The most successful companies in the world now build in public. Think about how much of Linear's development happens on X. Think about Vercel's radical transparency with their changelog.
"I don't have anything interesting to share." — You do. The problem you're solving, the code you wrote today, the design decision you're struggling with — all of it is interesting to someone on the same journey.
What This Looks Like in Practice
For me, building in public means:
- Daily updates on X about what I shipped, what I learned, and what I'm struggling with
- Open metrics — sharing download numbers, revenue, and user feedback
- Behind-the-scenes — screenshots, screen recordings, and notes from planning sessions
- Engaging with the community — responding to every comment, every DM, every piece of feedback
It's not a strategy. It's a way of working. And it's the most fulfilling way I've ever built products.
Start Today
If you're reading this and wondering whether you should build in public — yes, you should. Start small. Post what you worked on today. Share a screenshot. Ask for feedback on a decision. The magic isn't in going viral; it's in showing up consistently.
The best time to start was yesterday. The second best time is right now.
Follow along with my journey on X (@MintJane_) and check out what I'm building at MintJane and Workout Lens.