This site got 35,363 pageviews in its first six weeks. I didn't know. I found out from an automated Cloudflare email congratulating me on passing ten thousand, and my first reaction wasn't delight: it was embarrassment, because I hadn't touched it in weeks. Someone — or something — was arriving, and what they found was a still photo from June.
That's the starting point for this piece, because "building in public" has come to mean, almost always, publishing results. The screenshot of the metric that went up. The milestone. The month closed out. The problem with results as content is twofold: you can't verify them, and you can't use them.
You can't verify them because there's nothing behind the number. And you can't use them because a result doesn't tell you what to do on Monday. If I tell you my product has more than two thousand nine hundred tests, you have learned precisely nothing: you don't know if they're good, you don't know what order I wrote them in, you don't know which ones have saved me. A number without a mechanism is an ad.
"A number without a mechanism is an ad. A mechanism without a number is still useful."
So I publish how, not how much. The filter I use to decide whether something is worth publishing is a single question: can someone who wasn't there check it? In my repository that rule is written down literally: a receipt that doesn't survive the session isn't a receipt. It has to be versioned or in the pull request, and it has to be checkable by someone who wasn't in the room. If the only evidence that something worked is that I say so, it didn't work — I remember it.
The cost
Publishing the process carries a cost that publishing results does not: it forces you to publish the parts that don't work, too. Not in the abstract, with the decorative humility of "of course, we all make mistakes," but specific ones, with a date and a name.
Today, while I was working on this site, I discovered that my own product had spent months telling search engines that its canonical copy lived at a domain that serves nothing. The application is somewhere else. Every indexable page of a product I build with a fleet of agents and fourteen automated checks was pointing at a closed door.
None of my gates caught it, and the reason is the part that actually matters: they all checked that the address was well-formed and none of them checked that it answered. I could have fixed it quietly — that's what performance mode does, you correct the fault and publish the version where it never happened. I fixed it, opened the ticket, and I'm telling you here. Not because transparency is an abstract virtue, but because the failure carries a lesson anyone can take away: a check that validates shape does not validate reality.
The boring part is the work
The difference between building in public and performing in public shows up when the process is boring. A month spent fixing a canonical domain, reordering structured-data nodes and deleting four duplicate copies of the same definition does not make a good LinkedIn post. It makes a good record. And the trap of performance mode is that, with nothing shiny to show that month, you start choosing work by how well it tells. That's the moment the content stops documenting the product and starts steering it.
I also write this knowing that some of whoever reads it won't be a person. Language models are a real discovery channel now, and they cite what they can verify and attribute: a concrete mechanism, with a source, with a date. It happens that this is exactly what makes a text useful to a human being. I haven't had to choose between writing for people and writing for machines, and I'm fairly suspicious of anyone who tells you the choice is necessary.
Those 35,363 pageviews didn't change my strategy. They reminded me the record had stalled. The difference between the two reactions — rushing to publish a milestone, or going back to writing the process — is more or less the whole point of this piece. I don't publish the process because I'm generous. I publish it because it's the only part I can prove.
If AI is rewriting your job too, follow along
…or if you need someone to govern it in your product, work with me.