← blog
building-in-publicdeveloper-marketingtrustcraftwriting

Building in public is backwards: build first, then speak

I used to post the roadmap and the coming-soon teaser. Then I stopped. Why building in public is backwards, and the rule that beats it: build first, then speak.

high-tech agent scene holding microphone

I used to post the roadmap. The coming-soon screenshot, the "building something new" teaser, the thread narrating a feature I had not finished. It felt like momentum. Building in public, the advice everyone gives: share the journey, bring people along, market as you make.

I stopped. Not because visibility is bad. I publish more now than I ever did. I stopped because I had the sequence backwards, and the sequence is the whole thing.

Building in public, as most people practice it, means narrating intentions. You announce the thing before the thing exists. And announcing has two costs that nobody mentions in the "share your journey" advice.

What building in public actually rewards

The first cost is internal. Posting about the work lights up the same reward the work does. You write the announcement, the likes come in, and your brain files it under "made progress today." But you moved nothing. You can run this loop for weeks, feeling productive, shipping tweets instead of software. The narrating competes with the building for the same hours and the same dopamine, and narrating is easier, so narrating wins.

Attention is a loan; trust is a deposit

The second cost is external, and it is the one that actually matters. When you announce before you ship, you spend credibility on a promise. People give you attention for a thing that does not exist yet. That is a loan. You have to pay it back by shipping exactly what you described, on the timeline the excitement assumed. And unfinished work moves. The feature changes, the release slips, the idea turns out wrong. Hardware companies named the sharp version of this the Osborne effect: pre-announce the next thing and you can kill demand for the thing you already have. Now the version you shipped does not match the version people got excited about, and you have quietly spent trust to buy attention that already decayed.

Ship first and the transaction inverts. You build the thing, then you speak, and every word is backed by something a person can actually run. You are not asking for belief. You are reporting a fact. Attention spikes and fades no matter what you do, but trust earned against a real artifact compounds, because the next time you speak, people remember the last thing you said was true.

Build first, then speak

So the rule I follow now is boring and it works: let the work exist before the words about it. Not "never be visible." Visible constantly. But behind the work, not in front of it. Ship the small real thing, then write about the small real thing. The empty-database post went out after the tool was on PyPI and a reader could pip install it mid-sentence, not before.

This costs you the easy dopamine of the teaser and the pre-launch hype thread. What you get back is that you never owe anyone a thing you have not built, and every post you write is collateralized by something real. Over a year, the person who narrated intentions has a feed full of promises. The person who shipped first has a feed full of proof. One of those compounds.

Speak from behind the work, not in front of it.

Announce, and you borrow attention against work that does not exist. Ship, and you own it.

share