Build in Public: Resources for Indie Founders
Building in public means sharing a startup's real progress, revenue, and setbacks as they happen, not just announcing polished wins after the fact. For an indie founder, it turns a solo grind into something other people actually witness: one post, one metric, one honest update at a time. This page breaks down what the practice involves and points to a working example: MyTools itself.
What Building in Public Means for an Indie Founder
At its core, building in public is the habit of narrating a company's journey in real time, out loud, to anyone who wants to watch. That includes the good parts (a new signup, a feature ship, a revenue milestone) and the uncomfortable parts (a failed experiment, a missed deadline, a pricing mistake). The goal isn't performance. It's honest documentation of a solo founder's path, or a small team's path, from idea to product.
A few things this practice is not:
- It is not open source. Sharing a decision-making process and monthly revenue doesn't obligate anyone to publish their codebase. A founder can build in public while keeping the source private.
- It is not a marketing script. Founders who do this well share things marketers usually hide, like churn spikes or a pivot that didn't work.
- It is not limited to one platform. Most of the visible activity happens on X (formerly Twitter), but founders also build in public through blogs, newsletters, and community forums like Reddit's r/buildinpublic.
The practice grew out of the indie hacker community, a loose network of solo founders and small teams who bootstrap products instead of raising venture funding. Sharing openly became a substitute for the accountability a boss or a board usually provides. When nobody else is watching your progress, an audience of strangers online can fill that gap surprisingly well.
Why MyTools Builds in Public
I run MyTools as a solo operator under the handle @karakhanyans, and the directory itself is a build-in-public project, not just a site that writes about the concept. Every tool listed, every category page, and every update to the catalogue reflects decisions made in the open rather than behind a closed roadmap.
There's a fitting detail here: I built MyTools using Directify, a no-code tool listed in our own directory. That's a small but verifiable proof point. The site you're reading was assembled with a product from the very catalogue it curates, and that loop is exactly the kind of transparency this page is about.
Here's why that matters in practice:
- Trust with the indie hacker audience. Founders researching tools are more likely to trust a directory that's honest about how it was built and who runs it, rather than an anonymous "team."
- Accountability. Publicly committing to ship a new category page or fix a broken listing creates pressure to actually follow through, the same pressure any founder feels once an audience is watching.
- A community feedback loop. When people know who's behind a product, they send better feedback: which tools are missing, which categories feel thin, which listings are outdated.
A short transparency note, since fabricated statistics have no place here: MyTools currently lists 182+ tools across categories like no-code builders, developer utilities, and growth software, and the directory keeps growing as new indie products launch. That number is modest by design. It reflects a real, hand-curated catalogue rather than a scraped database.
The Core Elements of a Build-in-Public Practice
Most explanations of this term stop at "share your journey," which isn't specific enough to act on. Here's the framework I use when thinking about what a genuine build-in-public practice actually contains.
Transparency
Transparency means sharing decisions and setbacks alongside the wins. That's the hardest habit to build because instinct tells founders to hide the messy parts. A founder who only posts good news isn't building in public. They're doing marketing with extra steps.
Metrics Sharing
Metrics sharing is the most recognizable signal of the practice: posting monthly recurring revenue (MRR), traffic numbers, user counts, or churn rates in public. MRR screenshots are practically the genre's calling card on X. Sharing numbers, even small or embarrassing ones, gives an audience something concrete to follow instead of vague progress talk.
Audience Building
Audience building happens alongside the product, not after it launches. A founder who builds in public grows two things at once: the tool and the following of people who care whether it succeeds. That audience often becomes the first wave of users, beta testers, and word-of-mouth promoters.
Community Feedback
Community feedback is the return channel. Once people are watching your journey, they start replying, and their replies shape the roadmap. A founder who asks "should I build feature A or feature B?" in public gets real signal before writing a line of code, which beats guessing in isolation.
Accountability
Accountability drives most of what makes this practice work. Publicly stating "I'll ship this by Friday" creates a kind of social pressure that solo founders, who don't have managers or co-founders checking in, badly need. It's a self-imposed deadline with witnesses.
Here's the same framework as a quick checklist:
- Share both wins and setbacks, not just highlight reels
- Post real metrics (MRR, users, traffic) on a regular cadence
- Grow a following in parallel with the product, not after launch
- Ask for and act on community feedback before big decisions
- Make public commitments that create real accountability
If you want to see this framework applied step by step, our sibling guide on how to build in public walks through the tactics, and our build in public examples page profiles founders doing each of these five things well.
For a fast overview of the mindset behind this movement, this short video captures the pitch in under two minutes.
Where to Start: MyTools' Build-in-Public Resources
If you're new to the practice, here's a curated set of next steps rather than a wall of links to sort through yourself.
| Resource | What it's for |
|---|---|
| How to build in public | A step-by-step guide for founders ready to start sharing their journey |
| Build in public examples | Real founders and their public-building habits, profiled in depth |
| Discover indie products | Browse the wider MyTools catalogue for tools other founders are shipping |
| Solo founder resources | A hub built specifically for one-person teams |
| Submit your indie tool | List your own product once you're ready for visibility |
| No-code tools directory | The category Directify (MyTools' own build tool) belongs to |
| Marketing & growth tools | Tools that support the audience-building side of this practice |
A few specific listings worth a look if you're assembling your own stack for public building: Datafast for tracking the metrics you'll be sharing, Shipfast and Larafast for shipping product faster, and Microlaunch or Uneed for the launch-day audience push. None of these are affiliated with the sibling examples page. They're simply practical tools that show up again and again in indie founders' public-building stacks.
Follow the Journey
The definition on this page is useful, but watching the practice happen in real time teaches more than any static explanation can. I post ongoing updates, decisions, and numbers from running MyTools under @karakhanyans, and you're welcome to follow along as the directory grows.
If a video breaks down the tradeoffs of the practice better than text can, this one from Mercury weighs when building in public helps and when it might not.
From here, the most useful next step depends on where you are. If you're still deciding whether this practice is right for you, start with the "why" section above and the Mercury video. If you're ready to act, head to the how-to guide for the tactics, or submit your own tool once you have something worth sharing.
Frequently Asked Questions
What does it mean to build in public? It means sharing a startup's real progress, including revenue, decisions, and failures, openly and as it happens, rather than only announcing finished results.
Is building in public the same as open source? No. Open source means publishing code under a license anyone can use or modify. Building in public means sharing process and metrics; the codebase can stay completely private.
What do founders typically share when building in public? Most commonly: monthly recurring revenue (MRR), user counts, traffic numbers, product launches, roadmap decisions, and the reasoning behind pivots or feature choices.
Where do people build in public? Primarily on X, alongside blogs, newsletters, and forums like Reddit's r/buildinpublic community. Some founders also post progress on Substack or in dedicated indie hacker communities.
Why does MyTools build in public? Because trust, accountability, and community feedback compound faster in the open. Running a directory transparently, built with a tool from the directory itself, gives users a reason to believe the curation is genuine.
