In December 2013, Buffer published every employee's salary on its public website, along with the exact formula it used to set them. In the thirty days before that post, the company had received 1,263 job applications. In the month after, it received 2,886. The number more than doubled, and the co-founder Joel Gascoigne said the people now applying were a far better cultural fit than the ones who came before. That result became one of the founding stories of building in public, and it is still a good one. It is also nearly thirteen years old, and the calculus that made it work has shifted under our feet since.
I run more than one product at a time, and the question other founders ask me most often is a version of the same thing: do you build in public, or do you keep your head down? The question assumes there are only two settings, share everything or share nothing. In practice I do neither, and the line I draw turns out to have almost nothing to do with how open I am willing to be. It has to do with what a given piece of information is for.
The two things people mean by "in public"
When founders talk about building in public, they are usually running two very different things together under one label. The first is the thinking: the decisions, the mistakes, the reasoning behind why you built something one way instead of another. The second is the asset: the revenue figures, the growth rate, the roadmap, the system architecture, the exact stack that makes the product work. Buffer's experiment shared both at once, and in 2013 that was a defensible trade. Publishing the assets carried a real but survivable risk, and the trust you bought with the openness paid for it several times over.
That balance has moved, and it has moved fast. Arvid Kahl, who sold his last software business partly on the strength of publishing his Stripe-verified monthly revenue, wrote in April this year that he now would not share a single number. His reasoning is uncomfortable and, I think, correct. A business-minded person no longer needs to understand your code to copy you. They need a subscription to a capable model and the patience to write a decent prompt. Point an agentic coding tool at everything you have published over six months, ask it to study your product page by page and rebuild it with a small twist of its own, and a serviceable clone becomes a couple of weeks of work instead of a couple of years. The revenue threshold at which sharing your numbers used to feel safe, somewhere around twenty to thirty thousand dollars a month in his earlier writing, has in his view collapsed towards zero.
Why sharing the asset became the expensive half
There is a second cost to oversharing, quieter than the competitor problem and easier to miss, because it lands on you rather than on your market. It is what public commitment does to your own follow-through. In 2009 the psychologist Peter Gollwitzer and three colleagues published a study in Psychological Science called "When Intentions Go Public". Across four experiments they found that when other people noticed someone's identity-relevant intention, that person then pursued it less intensively than someone who had kept the same intention to themselves. In one study, law students who had told a researcher about their commitment to working hard gave up earlier than the students who had stayed quiet about it. The explanation they offered is a premature sense of completeness. Announcing the goal hands you a small dose of the identity you were chasing, and that dose quietly lets some of the pressure out.
Set the two findings next to each other and a shape emerges. The parts of building in public that feel boldest, posting the target, the revenue, the roadmap, are precisely the parts that carry the most downside. They pass a blueprint to anyone who wants to build against you, and they can drain the very drive you were trying to broadcast. The parts that feel almost too small to be worth posting, the reasoning and the hard lessons, are the parts that actually compound in your favour. That is an awkward inversion, because the modest half is the half most people skip.
What actually lasts
Look again at why Buffer's experiment aged well, and it is not the salary numbers, which were only ever a single moment in time. What lasted is that Buffer kept publishing the thinking behind how it runs, on ground it owned, and more than a decade later it is still the company people reach for when this subject comes up. Kahl's experience says the same thing from the other side. He still builds in public, but what he shares now are what he calls tripwires: the things he did not see coming and what happened when they went wrong, observations about his industry general enough that a direct rival cannot act on them, the texture of actually running the business day to day. He holds back anything that reads as a specification, the revenue, the customer count, and above all the system architecture and the exact dependencies, because those are the hard-won parts that took years to get right and would take a cloner minutes to lift.
Kahl's blunt version of this is that the product itself is no longer a moat, and neither is the ability to write the code, because a capable model now hands both to anyone who asks. What cannot be handed over is the thing that took years to accumulate: the data you have gathered, the judgement you have earned inside an industry, and the customer relationships built over months of meetings and back-and-forth. Those are safe to hint at precisely because they cannot be rebuilt from a blog post.
The principle sitting under both examples is the one I keep returning to. Share the things that make it interesting to follow your journey, and keep the things that make it easy to copy your work. The rest is detail, and detail is rarely worth the exposure.
None of this is an argument for going quiet. Building in private, the way I mean it, is not stealth mode, and it is not secrecy for its own sake. Plenty of founders read the cloning risk, conclude they should say nothing at all, and then wonder why nobody knows they exist. The trust that Buffer earned and that Kahl still trades on is real, and you only earn it by showing up and being useful in public. The skill is not choosing between loud and silent. It is being genuinely open about one category of thing while staying disciplined about another, often in the same breath, without the reader ever feeling the join.
What I actually do
So here is how I split it in practice, across the products I run.
- I share the reasoning and keep the numbers. If I write about a project, I will happily explain why I chose one route over another and what I got wrong along the way, because that is genuinely useful to another operator. I will not publish the revenue, the client count or the margin, because those are the figures that tell a competitor whether you are worth chasing in the first place.
- I keep the architecture private. How the components fit together, which services carry the heavy load, the specific integrations that took months to make reliable, none of that goes out in public. A systems diagram is a gift to anyone trying to rebuild what you already have, and there is no amount of goodwill that makes handing it over worthwhile.
- I publish on ground I own. The substantial thinking goes on my own site first, where it stays mine and stays findable in five years' time. Social feeds are for pointing people towards the work, not for housing it. If a platform changes its rules or disappears, which they do, the work does not leave with it.
- I write up what is done, not what I am about to do. This is the Gollwitzer finding made practical. I have stopped announcing goals and roadmaps before I have delivered them, because the announcement spends motivation I would rather keep for the delivery itself. Writing something up after it works costs me nothing and still teaches the reader something real.
- I decide item by item, with one test. Before anything goes public I ask whether sharing it makes my work more interesting to follow or simply easier to clone. If it is the former it goes out, and if it is the latter it stays in. Most of these calls are not close once you put the question in those exact words.
The point
Building in public and building in private were never really opposites, whatever the online advice implies. They are two questions asked of the same piece of information: does sharing this earn trust, or does it hand someone a shortcut? Answer that honestly, one item at a time, and the wall between public and private stops behaving like a wall at all. It becomes a filter, and for anyone building something worth copying, it is one of the more useful filters you can run.