Building in public
How to build in public
I shipped three apps before I posted about any of them, which was a mistake. Building in public is mostly the discipline of saying what happened this week.
-
Post the work, not the milestone.
Launches are one day. The other three hundred are the interesting part, and they are what people follow. A screenshot of something half-finished gets more response than a polished announcement.
-
Pick one place and stay there.
Posting the same thing to five platforms means doing five things badly. Choose where the people you want to reach already are, and let the rest go.
-
Say the number, whatever it is.
Twelve downloads is a real number. Vague growth language reads as hiding something, and it usually is. Specific and small beats impressive and unfalsifiable.
-
Show the thing that broke.
Nobody learns from a success story with the failures edited out. The post about the bug that cost you a weekend is the one people save.
-
Write for one person you know.
Pick an actual friend who works in something else. If they would understand it, it is clear. If it needs jargon, it needs rewriting.
-
Keep a cadence you can hold on a bad week.
Weekly is sustainable. Daily is not, and stopping is worse than never starting because it reads as a project that died.
-
Do not narrate the plan.
Announcing what you are about to build spends the satisfaction before the work. Post after the commit, not before it.
-
Reply to everyone at the start.
When five people comment, replying properly to five people is how you get fifty. This stops scaling eventually, which is a nice problem.
-
Keep the receipts.
Screenshots, commit counts, the graph on the bad month. A year of that is a body of evidence, and it becomes the raw material for everything longer you write.
-
Expect it to feel pointless for months.
Small numbers early are not a signal. The compounding is real but slow, and most people quits in the stretch where it looks like nothing.