Build in public, publish artifacts not intentions
The part everyone does is the part with evidence against it
Thesis
A counter on a site I built reads 00 / 30 PRODUCTS BUILT, PHASE 01: DISCOVERY, 0% COMPLETE. It has read that since launch. In the same period, on the same GitHub account, seventeen repositories appeared.
That gap is the whole subject of this article, and it is not a discipline problem. Two completely different practices travel under the same name.
One is publishing artifacts: here is a thing that exists, here is what it does, here is what broke. The other is publishing intentions: here is what I am going to make, here is my target, here is my progress bar.
The first is a distribution strategy. The second is a psychology experiment that the published research says usually goes the wrong way. Most people who set out to build in public do the second, because it is easier and it produces engagement sooner, and then conclude they lack consistency when the counter stops moving.
Context
Build in public became a default posture some time around 2019 and hardened into a genre. Its logic is sound on the face of it. Distribution is the binding constraint for a small team, attention is cheaper to earn while you are making something than after you have finished, and an audience assembled during development becomes the first cohort of users.
The genre also produced a template, and the template is where the trouble starts. The template opens with a commitment. Twelve startups in twelve months. Thirty products. A public revenue target with a screenshot of the dashboard. A number in a bio.
That commitment does two things at once. It generates immediate interest, because a stated target is a story with a cliffhanger. And it converts every subsequent day into either evidence of progress or evidence of failure, in public, against a number chosen before you knew anything about the work.
Almost nobody separates those two effects when deciding to do it.
Research
On public commitment as a substitute for action. Gollwitzer, Sheeran, Michalski and Seifert published a set of experiments in Psychological Science in 2009 under a title that says it plainly: "When Intentions Go Public: Does Social Reality Widen the Intention-Behavior Gap?" Participants stated identity-relevant intentions. Some had those statements noticed by another person; others did not. The ones whose intentions were noticed subsequently engaged in less goal-directed activity, and reported feeling closer to possessing the identity they had claimed. The authors describe it as a premature sense of completeness. Being seen to intend something partly satisfied the need the action was supposed to satisfy.
This is not a fringe result and it should be uncomfortable for anyone whose bio contains a target. It says that announcing "I am building thirty products" delivers a portion of the reward of having built them.
On what actually closes the gap. The same researcher's earlier work points the other way and is worth pairing with it. Gollwitzer's 1999 paper on implementation intentions found large effects from a very different kind of plan: not "I intend to be someone who ships", but "when situation X arises, I will do Y". Specific, situational, unglamorous. The distinction that matters is not public versus private. It is identity goal versus concrete plan.
On why revealing work pays. Harhoff, Henkel and von Hippel, in Research Policy in 2003, examined why innovators voluntarily reveal what they have made even when they could keep it. Their answer is that free revealing generates reciprocal information, improvements from others, and reputational returns that frequently exceed the value of secrecy. That is the strongest empirical foundation under the practice, and note what it is about: revealing innovations, meaning things that exist.
On the signalling function. Lerner and Tirole's "Some Simple Economics of Open Source", in the Journal of Industrial Economics in 2002, analysed why capable engineers contribute unpaid work to public code. A large part of their answer is signalling: public artifacts are legible to future employers and collaborators in a way that private accomplishment is not, and the signal is stronger when the work is visible and attributable. Again the mechanism runs through the artifact.
On why the successes you have seen mislead you. Denrell's 2003 work in Organization Science on undersampling of failure explains the structural problem with learning from public build stories. You observe the survivors, because failures stop publishing, and the strategies that appear to distinguish winners are frequently the same strategies used by the people who disappeared. The build-in-public canon is a survivor sample by construction. The people whose thirty-product commitments went nowhere deleted the thread.
Argument
Publish retrospectively, not prospectively.
Every claim in a retrospective post is checkable at the moment you publish it. "I shipped this, here is the URL, here is what I got wrong" carries no forward obligation, cannot be falsified by next week, and costs nothing psychologically because the work is already done. A prospective post borrows against work you have not started, at a rate you set while ignorant.
Retrospective publishing is also more useful to read. A target tells the reader about your ambition. A teardown tells them something they can use.
Drop the denominator.
00 / 30 is worse than 00, and it is worse than nothing at all. A denominator you chose arbitrarily creates a permanent public deficit and turns the honest state of the work into an embarrassment. Counters, progress percentages and phase labels all share this property: they promise a shape the work is not obliged to follow.
If you want a number in public, make it a count of what exists. Counts only go up, they never imply a shortfall, and they are true on the day you write them.
Public repositories are not the same as building in public.
This is the distinction I got wrong for months. Making code visible satisfies the letter of the practice and none of its function. Visibility without narration produces no distribution, because nobody browses a stranger's repository list, and it produces a weak signal, because an undescribed repository with no README communicates almost nothing about judgement.
Building in public requires the artifact plus an account of the artifact. The account is where the reasoning lives, and reasoning is the only part of the work that transfers to a reader.
The cost nobody mentions: it changes what you build.
This is the argument I would make most strongly, and it is the one least often raised.
An audience rewards work that is legible in a screenshot. That selection pressure is real and it operates continuously. Work that photographs well gets published, gets response, and gets continued. Work whose value only appears after weeks of unglamorous iteration gets abandoned, because there is nothing to post.
So the practice quietly rewrites your roadmap toward demo-shaped features and away from the reliability, instrumentation and distribution work that decides whether anything survives. Nobody posts a screenshot of an evaluation harness. Nobody gets replies for adding analytics. Those are frequently the highest-value things on the list.
If you build in public, you have to notice this bias and price it in, because it will not announce itself.
Distribution is the honest reason to do it, and it should be measured.
Strip away the accountability story and the case for the practice is straightforward: it is cheap distribution and a durable public signal, supported by both the free-revealing and the open-source signalling literature. Treated that way it becomes measurable. Did anyone arrive from the post. Did anyone use the thing. Did anyone reply with something you did not know. If a build-in-public habit produces none of those over a few months, it is a journal with extra steps, which is a fine thing to keep and not a growth channel.
Examples
The commitment format. "Thirty products in a year", published before product one. Produces early interest, then a widening public gap, then silence. The Gollwitzer result predicts the shape of this precisely, and it is the most common format in the genre.
The artifact format. One post per shipped thing. What it does, who it is for, what it does not do yet, what broke. No forward promise. Each post is durable and independently useful, and the collection becomes a body of work rather than a scoreboard.
The reasoning format, which is the strongest. Not "I shipped this" but "here is the decision I got wrong and what it cost". This is the version that gets read by the people worth being read by, because it demonstrates judgement rather than throughput. It is also the only format where a failed project is as publishable as a successful one, which removes the incentive to hide the failures and therefore removes the survivorship distortion at source.
The metrics format. Public revenue dashboards work for a narrow group: people whose audience is other builders and whose product is sold to that audience. For everyone else the numbers are either too small to help or a reason for prospective customers to worry about longevity.
Counterargument
"Public commitment is one of the best-established behaviour change tools there is. You are citing one paper against decades of practice."
The strongest version of this is not hand-waving. Cialdini's work on commitment and consistency documents a robust tendency to act in line with positions we have publicly taken, and it has held up across a wide literature. Accountability groups, training partners, stated deadlines and public weight-loss commitments all rest on it, and plenty of people report that a public target is the only reason they finished anything.
There is a sharper version aimed directly at me: this article is a rationalisation. A person whose counter reads 00 / 30 has an obvious motive for arguing that public counters are harmful, and the intellectually honest reading of that situation is that the mechanism worked, showed a real shortfall, and is now being blamed for the accuracy of its reporting.
Where this is right. The self-serving objection lands. I would not have written this article if the counter had moved. And Cialdini's mechanism is real: for bounded, well-specified, short-horizon commitments, public statement does help, and I would not argue otherwise.
Where I think it is wrong. The two literatures are compatible once you separate the kinds of commitment. Cialdini's consistency effects work on specific, verifiable, near-term actions with a clear completion condition. Gollwitzer's identity-goal effect works on broad self-descriptions of the person you intend to become. "I will publish this teardown on Thursday" is the first kind. "I am building thirty products" is the second. The genre overwhelmingly produces the second, and it produces it at the moment of least information, before you know how long anything takes.
And on the self-serving reading: the counter did report accurately, and I have written that up as a failure elsewhere rather than deleting it. What I am disputing is the claim that setting it caused any of the seventeen things that got built. It did not. They got built for other reasons, and the counter recorded none of them, because they were not the thirty products it was waiting for.
Practical implications
Publish what exists, in the past tense. No targets, no roadmaps presented as promises, no phase labels.
If you want a public number, use a count with no denominator. Seventeen shipped is a fact. Seventeen of thirty is a deficit you invented.
Write one page per artifact. What it does, who it is for, what is missing, what you learned. Four lines is enough, and four lines is infinitely more than an undescribed repository.
Make the reasoning the content. Decisions and their consequences travel; feature announcements do not.
Publish the ones that failed. This is what makes the whole practice honest, and it is also the only defence against your own survivorship bias.
Audit for demo bias every month. List what you shipped and ask which items were chosen because they were postable. If the unglamorous work is consistently losing, the audience is running your roadmap.
Measure it as a channel or stop calling it one. Arrivals, activations, useful replies. If all three are zero after three months, keep the habit and drop the label.
Convert identity goals into implementation intentions. Not "I am someone who ships weekly". Instead: "on Friday morning, before anything else, I write up whatever shipped this week". Situational, specific, and supported by the better half of the evidence.
My perspective
Labelled as opinion, and specific to my own record.
Seventeen repositories appeared on my GitHub account between February and June 2026. Every one is dated and checkable. In the same window, the site I built specifically to document that work published nothing, and its counter still reads 00 / 30. Six of the seventeen have no description at all, which means real work is sitting in public and communicating nothing.
The mistake was not laziness about posting. It was ordering. I built the documentation product before I had the documentation habit, and a build-in-public site with an empty projects page is a stronger negative signal than no site, because it demonstrates the exact failure it was meant to solve. A markdown file per repository would have been worth more than the site, and it would have taken an afternoon.
The second thing I believe, less comfortably: the counter was a substitute. Setting up a project called BuildWithDev, choosing the target, designing the phase labels, all of that felt like beginning. Gollwitzer's finding describes what I did, and I did it without knowing the research existed, which is roughly what you would expect from a well-replicated effect.
What I would tell anyone starting: your repository list is already building in public if you write four lines about each thing in it. That is the whole practice. The site, the counter and the commitment are optional, and the counter is worse than optional.
Conclusion
Build in public is two practices with one name. Publishing artifacts has a real mechanism behind it, documented in the open-innovation and open-source literature: revealing generates reciprocal information and a legible signal. Publishing intentions has a documented mechanism running the other way, in which being seen to intend something delivers part of the satisfaction of doing it.
The version worth doing is retrospective, artifact-shaped, includes the failures, and carries no denominator. The version most people do starts with a number, and the number is the part that does not work.
Sources
- P. M. Gollwitzer, P. Sheeran, V. Michalski and A. E. Seifert, "When Intentions Go Public: Does Social Reality Widen the Intention-Behavior Gap?", Psychological Science 20(5), 2009, 612–618.
- P. M. Gollwitzer, "Implementation Intentions: Strong Effects of Simple Plans", American Psychologist 54(7), 1999, 493–503.
- D. Harhoff, J. Henkel and E. von Hippel, "Profiting from voluntary information spillovers: how users benefit by freely revealing their innovations", Research Policy 32(10), 2003, 1753–1769.
- J. Lerner and J. Tirole, "Some Simple Economics of Open Source", Journal of Industrial Economics 50(2), 2002, 197–234.
- J. Denrell, "Vicarious Learning, Undersampling of Failure, and the Myths of Management", Organization Science 14(3), 2003, 227–243.
- R. B. Cialdini, Influence: The Psychology of Persuasion, Harper Business: commitment and consistency.
- P. Sheeran, "Intention-Behavior Relations: A Conceptual and Empirical Review", European Review of Social Psychology 12(1), 2002, 1–36.
- buildwithdev.xyz, homepage counter reading
00 / 30 PRODUCTS BUILT,PHASE 01: DISCOVERY,0% COMPLETE. Recorded as A30 inSOURCE_INVENTORY.md. https://buildwithdev.xyz - github.com/TheDevChopra, nineteen public repositories, eighteen authored and one fork. Recorded as A2. https://github.com/TheDevChopra
Related reading in this archive
- BuildWithDev: the case study about the counter in the opening paragraph
- The Build Archive: the seventeen repositories, dated and listed
- Why I build many small products instead of one large one
- What seventeen products in five months actually taught me