Why we share our work before it's ready, and how transparency accelerates learning in software development.
The Default is Silence
Most software development happens in private. Teams build features behind closed doors, iterate in isolation, and only reveal their work when it's "ready." This makes sense for competitive businesses, but it's suboptimal for learning.
When you build in private, your feedback loop is limited to your team. When you build in public, your feedback loop includes everyone who sees your work.
What Building in Public Means
For us, building in public involves:
Weekly demos — Every Friday, we record a short video showing what we built that week. Not polished marketing material—raw, honest demonstrations of works-in-progress.
Open repositories — Our experimental code is public. You can see our false starts, our refactors, our "TODO: fix this later" comments.
Research notes — We publish what we're learning as we learn it, not just polished conclusions.
Transparent roadmaps — Our plans are visible, including the ideas we've shelved and why.
Why This Works
Faster Feedback
Last month, we shared an early prototype of our voice coding interface. Within 48 hours, we had:
- 3 bug reports we hadn't noticed
- 2 feature suggestions that became priorities
- 1 contribution from a community member
- Countless small insights from watching people react
This feedback would have taken weeks to gather through traditional user research.
Accountability
Public commitments create healthy pressure. When you tell people you're working on something, you're more likely to follow through.
Unexpected Connections
Building in public attracts like-minded people. Our best collaborators found us through public posts about our work.
The Risks
Copying: Yes, competitors can see what you're doing. In practice, execution matters more than ideas.
Embarrassment: Early work is often embarrassing. We've learned to embrace this.
Distraction: Public engagement takes time. We're deliberate about when we engage vs. when we focus.
A Practical Framework
If you're considering building in public, start small:
- Share one thing per week — A screenshot, a thought, a question
- Respond to feedback — Don't just broadcast; engage
- Be honest about uncertainty — "We're trying this approach" is more valuable than false confidence
- Document failures — What didn't work is often more instructive than what did
Conclusion
Building in public isn't about marketing or attention. It's about creating faster feedback loops and connecting with people who share your interests.
The best work happens in community. Opening up your process is an invitation for others to contribute, critique, and collaborate.
This essay is part of our commitment to sharing our process. Follow along as we build developer tools in public.