Key takeaways
- Build in public x means sharing your roadmap, metrics, and mistakes on X so strangers become your first users before launch.
- Four categories stay private at every stage: unreleased pricing experiments, user data, private roadmap bets, and anything a competitor could weaponize.
- Pre-launch, share process over progress: one build log, one problem post, and one decision post per week takes under an hour total.
- Once you have paying users, share rounded ranges and churn lessons instead of raw dashboards to protect individual users.
- Cap posting at 30 minutes daily and slice one Friday build log into five posts for the following week.
Build in public x means posting your roadmap, metrics, and mistakes on X while you ship, so strangers become your first users before launch. This guide gives you a share-vs-withhold framework for three stages: pre-launch, first users, and first 100 paying users. You will know exactly what to post, what to keep private, and how to keep it sustainable.
What is build in public, and why does it work for solo founders?
Build in public means sharing your work as it happens: the roadmap, the build logs, the revenue numbers, the mistakes. Pieter Levels popularized the approach by publishing his MRR openly, and it's now a recognized playbook for indie founders (levels.io).
The mechanism is simple. Attention compounds into trust, and trust converts into distribution. A stranger who has watched you ship for six weeks arrives pre-sold; you didn't run ads, you ran a streak.
For a solo founder with zero users and no budget, this matters because organic reach is the only channel you can afford. Every post is a small deposit in a distribution account that pays out later.
The discipline is deciding what to share and what to hold back, which is what the rest of this guide covers. For the mechanics of turning posts into a loop, see build in public: turn build logs into a growth loop.
What should you never share when you build in public?
Build in public works because you trade transparency for attention. Some information, once shared, hands competitors an advantage or burns trust with users. Keep four categories private at every stage.
The four categories that stay private at every stage
Unreleased pricing experiments. Testing $9 vs $19? Post the result after it settles, not the test itself. Competitors can undercut you mid-experiment, and readers anchor on numbers that may never ship.
User data. Never share names, emails, revenue per user, or screenshots with identifying details. One leaked customer kills the trust your first 100 paying users are built on.
Private roadmap bets. Share the direction, not the differentiator. "Working on AI search visibility features" is fine; the specific mechanism you plan to ship is what stops a faster competitor from cloning it.
Anything a competitor could weaponize. Churn spikes, failed experiments, and honest losses build goodwill, but frame them with the lesson attached. Raw vulnerability without a takeaway just reads as struggling.
The habit that keeps this easy: log everything privately, then decide what to publish (we cover that workflow in turning logs into revenue).
What should you share before launch, with zero users?
Why process beats progress before you have a product
With no users and no revenue, your only raw material is how you build. Post the process: the stack decision between Lovable and Cursor, the prompt that finally fixed your auth flow, the feature you cut. Vibe coders trust builders who show the messy middle, not a launch-day reveal.
A simple pre-launch rotation works: one build log per week (what shipped, what broke), one problem post (the pain your product attacks, in the words your future users use), and one decision post (why you chose Postgres over Supabase, why you skipped a landing page). That is three posts a week you can write in under an hour total.
Skip vanity metrics entirely. Nobody expects pre-revenue numbers, and faking traction reads instantly. What attracts first followers is specificity: "I spent 40 minutes fighting a webhook" beats "making progress!"
One warning: process posts that dump features with no context leak attention instead of building it. HeyCatch's guide to build-in-public content mistakes covers the signs your posts are losing readers.
Pick platforms where builders already hang out. Pew Research's ongoing surveys of who uses which social platform show X and Reddit skew toward tech-heavy audiences, while LinkedIn mixes in more corporate roles, so match your process posts to the room.
What should you share once the first users arrive?
Your first ten users change what you can post. Before launch, you shared plans and screenshots. Now you have real signals: signups, activation, churn, and the reasons people leave. That is the content other founders actually want, because it is evidence, not opinion.
How to share numbers without exposing individual users
Round everything and report ranges, not identities. "9 signups last week, 2 activated, 1 churned after day three" teaches more than a raw dashboard screenshot, and it protects the two users who wrote you support tickets. Never quote a user by name without asking first.
The churn lesson is the highest-value post you can write. Say what the user told you, what you changed, and whether it worked. A feature decision framed as "three users asked for X, we built it, here's what happened" doubles as validation for your roadmap and shows you ship daily growth moves, not just talk.
For the full framework on sharing traction without chasing applause, see build in public: a guide to traction, not applause.
What changes when you hit your first 100 paying users?
Revenue screenshots stop being the whole story. At this stage, share conversion rates, churn, and pricing experiments instead of raw MRR, because those teach your audience more and reveal less to copycats.
When transparency becomes a competitive liability
Once money moves, competitors read your feed as free market research. Your exact pricing, churn percentage, and channel-by-channel numbers tell anyone with a Cursor project what to clone and how to undercut you. Pieter Levels built his brand on open metrics via his public dashboards, and his products have been widely cloned anyway, which is the clearest signal that full transparency has a ceiling. We break down the pattern in build in public: a competitive liability in disguise.
The practical shift: keep the narrative, drop the numbers that map directly to your playbook. Share that a pricing test worked, not the price. Share that Reddit drove signups, not which subreddits or what cadence.
What to stop sharing entirely: your exact revenue by channel, failed experiments competitors can learn from for free, and any automation workflow that took you weeks to build.
How do you run a build-in-public week without burning out?
Batch the work, post daily, and let one build log feed a week of content. The mistake most solo founders make is treating every post as a fresh creative project. Instead, you already produce the raw material every day: the code you shipped, the bug that ate your afternoon, the number that moved. The workflow below turns that existing output into a repeatable 30-minute routine, so posting becomes maintenance rather than a second job.
The 30-minute daily posting routine
Pick one fixed slot, same time every day, and cap it at 30 minutes. Spend the first 10 writing one raw note about what you did today: what you built, what broke, one number if you have one. Spend the next 10 turning that note into a single post for your primary platform. The last 10 go to replies: answer two or three people in your niche, because replies are where zero-user founders actually get seen. If a post needs more than 10 minutes of editing, it is too polished. Ship the rough version.
Turning one build log into a week of posts
Friday, write one honest build log: what shipped, what failed, what next week looks like. That single document becomes five posts. Monday is the win, stated plainly with a screenshot or a number. Tuesday is the failure, because the story of the bug that cost you six hours outperforms the feature it blocked. Wednesday is the decision: one fork in your roadmap and why you chose the path you chose.
Thursday is a lesson written for the version of you from a month ago. Friday is the log itself, posted as-is. Nothing new gets created during the week; you are only slicing material you already made while building. This is the whole system: one hour of writing per week, five minutes of slicing per day, and a posting habit that survives the weeks when shipping is hard and you have nothing clever to say.
Which platforms are worth a solo founder's posting time?
With zero audience, match the platform to where your effort compounds. Reddit and indie communities reward specificity; X rewards consistency; LinkedIn rewards patience you may not have.
| Platform | Effort per useful post | Payoff at zero users | Best move |
|---|---|---|---|
| High (read rules, reply in threads) | Fast, but burns out fast | Answer questions in 2-3 niche subs, 30 min/day | |
| Indie communities (Indie Hackers, WIP) | Low | Slow but warm | One weekly milestone post |
| X | Medium | Slow without followers | Daily build-in-public note, reply to 5 builders |
| Medium | Slowest for SaaS buyers | Skip until you have B2B traction |
Founders on Indie Hackers repeatedly describe content workload as a burnout driver, so pick two platforms, not four. Reddit plus one community covers the "where do my users hang out" question with the least time.
How do you know if your build-in-public content is working?
Ignore likes and follower count. The signals that matter, in order of strength: DMs asking about your product, profile visits before launch, signups you can trace to a specific post, and replies from people who describe your exact problem back to you. If nobody's DMing or clicking through after a month of posting, the content is entertaining the wrong audience.
Signals that say you're oversharing or leaking users
Watch for three warnings. First, you spend more time documenting the build than shipping, and your roadmap slips. Second, posts about features nobody asked for get engagement but zero product questions, which means you're performing for other builders, not future users. Third, you share metrics or ideas that a faster clone could ship before you do.
A simple weekly check: pick your last five posts and count how many produced a DM, a signup, or a reply from a potential user. If the answer is zero two weeks running, change what you share, not how often.
FAQ
Does build in public still work if I have no audience and no users yet?
Yes, and zero users is the best starting point because your raw material is process, not metrics. Post build logs, stack decisions, and the problem you are attacking, three posts a week written in under an hour total. Replies in your niche are where unknown founders actually get seen, and specificity beats polish.
How much time per day does build in public actually take?
Cap it at 30 minutes daily: 10 writing a raw note about what you did, 10 turning that note into one post, 10 replying to two or three people in your niche. On Friday, spend one hour writing a single build log that slices into five posts for the following week.
Can build in public hurt my product if competitors copy my roadmap?
Yes, once money moves. Your exact pricing, churn percentage, and channel-level numbers tell anyone with a Cursor project what to clone and how to undercut you. Even Pieter Levels, who built his brand on open metrics, has seen his products widely cloned. Keep the narrative and drop the numbers.
Should I share revenue numbers when I'm pre-revenue or under $1k MRR?
Pre-revenue, skip vanity metrics entirely, because nobody expects numbers from you and faking traction reads instantly. Under $1k MRR, round everything and report ranges instead of raw screenshots so individual users stay anonymous. As you approach 100 paying users, shift toward conversion rates, churn, and pricing experiments.