How to Build in Public Without Giving Away the Business

Mercury lists the risks plainly: exposing strategic thinking to competitors, pressure to project confidence during slow or messy periods, time taken from customers and product, and public feedback that amplifies loud opinions rather than informed ones (Mercury).

The copying risk has grown. Arvid Kahl, who credits building in public, including sharing his revenue figures, with the sale of his previous company FeedbackPanda, argues that the game has changed. He observed that founders used to stop sharing financial details once revenue reached a level that made them worth copying. With AI coding agents, he writes, that threshold "has effectively collapsed to zero": someone can ask a model to gather everything a founder has said about their business and turn it into a competing product in days or weeks (The Bootstrapped Founder). His conclusion is that "product isn't a moat. Software engineering capability isn't a moat. Not anymore."

There are quieter costs too. A Mercury feature on the subject notes that oversharing can reveal to customers or investors that a founder is greener or less certain than they realized, and quotes a consumer brand founder who stepped back from posting after noticing she rarely bought from the founders she followed, and wondered whether the same was true of her own audience (Mercury). Clark makes a related point about fundraising: public momentum helps when things are going well, but "if growth slows down, the strategy kinda falls apart" (Social Files).

Mercury suggests replacing "should I build in public?" with narrower questions (Mercury):

Add one more question from Clark: does the audience your posts attract include your customers? He describes a founder whose build-in-public posts attracted software founders rather than the consumer brand owners he was selling to, and notes that his own agency's metrics would attract other agency owners, who are not his buyers (Social Files). Founder audiences mostly attract other founders. That is valuable if you sell to founders, and much less so if you sell to dentists.

Mercury also notes that building in private is a legitimate strategy, especially in competitive or regulated markets, at the cost of needing more deliberate distribution work later (Mercury). Many founders land in between: open about lessons, closed about numbers and plans.

If you are unsure, treat it as an experiment with an end date. Commit to a set number of posts over a few months, write down what you expect to gain, such as customer conversations, beta signups or candidate applications, and track where each one came from. At the end, compare the results with the hours spent. If the people engaging are peers rather than buyers, and the posts are not producing conversations that matter, scale back without guilt.

Mercury's first tactical tip is to decide at the start which categories of information are always private, such as financial details or security practices, so you do not second-guess every post (Mercury). Kahl's personal list goes further. He no longer shares any numbers: not customer counts, revenue or expenses. He would not share system architecture, such as how his data pipelines are built, or dependencies, such as which services he uses for key steps, because those are "breadcrumbs to a clone" (The Bootstrapped Founder).

A working policy:

Kahl illustrates the difference between a safe and an unsafe level of detail. Saying a product added a particular integration and customers like it is fine. Saying that since adding that integration for five core features, a specific number of customers chose a particular pricing tier gives "far too much insight into the financial underpinnings of your business" (The Bootstrapped Founder).

Check your obligations as well as your preferences. Customer contracts, partner agreements and confidentiality clauses may restrict what you can say about who you work with or what you built for them, even in a positive post. When a customer story is the best content you have, ask for permission in writing and let the customer review the draft.

Write your own version of this table, share it with co-founders and early staff, and follow it. A shared policy prevents an employee's enthusiastic post from leaking what the founder kept private.

Kahl reduces the whole decision to one filter: share things that make it "interesting to participate in your journey, but not easy to clone your business." If a post is not interesting, nobody engages, and you have added risk for nothing. If it makes copying easy, "you're building your own competitor" (The Bootstrapped Founder).

Before publishing, run each draft through a short checklist:

1. Would a competitor learn a number, a vendor, an architecture or a plan from this?
2. Could someone feed this post, plus my last ten posts, into an AI tool and get a usable spec?
3. Does it reveal anything about a customer that they have not approved?
4. Would I be comfortable if a prospect or investor read this during a bad month?
5. Is there a lesson in it that someone in my audience could use?

Questions one to four should be "no". Question five should be "yes". The second question matters because individual posts can be harmless while a pattern across many posts reveals the full picture.

Timing is another lever. Many lessons are just as useful to your audience months later, when the decision behind them no longer reveals a current plan. Writing about a pricing change after it has settled, or about a feature after it has shipped and been copied anyway, keeps the story honest while giving competitors nothing they could act on in time. A delay of one product cycle is often enough.

Failory's list of common content types includes work-in-progress screenshots, strategies that worked, obstacles and how they were overcome, requests for feedback, quotes from users and regular updates (Failory). With the private categories above removed, the strongest formats are:

• The lesson post. What you tried, what happened and what you would do differently. Mercury suggests focusing on learnings and decision-making rather than performance, which keeps the conversation grounded in insight rather than optics (Mercury).
• The decision post. A choice you faced, the options and why you chose one, without the sensitive numbers.
• The tripwire post. Something unexpected, such as a strange customer request or a hard bug, and what it taught you.
• The feedback request. A design or idea you want opinions on, shared with people likely to be customers.
• The customer story. With permission, the problem a customer had and how you helped.
• The milestone post. A launch or a hire, framed around what it means for customers rather than around metrics.

Paddle's collection of build-in-public examples includes monthly round-ups, how-to threads and ask-me-anything sessions, all of which can work without revealing financial detail (Paddle).

Choose one channel to start. Failory recommends focusing on a single channel at first, picked for "channel-market fit", meaning the place your potential customers already spend time, because staying consistent across many channels while building a company is very time-consuming (Failory).

Mercury's third tip is to choose channels you can sustain: consistency matters more than volume, and occasional thoughtful posts beat burning out from constant posting. It also recommends revisiting the decision regularly, since what makes sense early may not make sense months later (Mercury).

Practical habits:

• Time-box it. Set a fixed weekly slot for writing and engaging, and do not let it spill into product or customer time.
• Write from your notes. Your weekly review, decision log and customer conversation notes already contain most of what is worth sharing. Turning them into posts takes less time than starting from a blank page.
• Be human, not polished. Marc Köhlbrugge, a long-time advocate of building in public, tells Mercury that a common mistake is being too polished, and that "the lesson is to kind of be human" (Mercury).
• Narrow the scope as you grow. Mercury observes that as stakes increase, founders often shift toward outcomes, milestones and lessons, keeping unfinished ideas, detailed metrics and forward-looking strategy private (Mercury).
• Protect your privacy. The same Mercury feature notes that Köhlbrugge stopped posting how much he earns and his specific whereabouts as his audience grew (Mercury).

An AI assistant can help turn notes into drafts and check a draft against your private-information policy before you post. Keep a human, ideally you, as the final reviewer of anything that goes out under your name.