A tech blogger argues that the common practice of «building in public» by announcing products before they're finished might be backwards. This approach, which involves sharing intentions early, can incur significant hidden costs for developers and projects.
So, is the popular «building in public» approach actually backwards? This question is vital because it means many of us might be wasting our time and energy inefficiently when trying to engage an audience in our product development journey. Traditionally, developers are advised to share everything: the roadmap, «coming soon» screenshots, «we're building something new» posts, and narrating features that aren't even finished yet. The common feeling was that this generated momentum and attracted attention. However, a tech blogger recently revealed they stopped this practice; not because visibility is bad, but because they realized the sequence was backwards. «Building in public,» as most people practice it, means narrating intentions. You announce the thing before the thing exists. And this early announcement comes with costs that aren't usually mentioned. The first cost is internal. When you post about future work, you get the same dopamine reward as doing the actual work. Likes and comments on an announcement make your brain register it as «progress made today,» when in reality, you've shipped nothing tangible. You can run this loop for weeks, feeling productive while shipping tweets instead of real software. Narrating competes with actual building for the same hours and dopamine, and since narrating is easier, it often wins. The second cost is external, and it's the more significant one. When you announce before you ship, you spend your credibility on a promise. People give you attention for a thing that doesn't exist yet, and that's a loan. You have to pay it back by shipping exactly what you described, on the timeline the initial excitement assumed. But unfinished work is always moving. Features change, releases slip, and the original idea might turn out to be wrong. If the final product doesn't match the promise, you quietly lose the trust you built. Hardware companies named the sharp version of this the «Osborne effect»: pre-announcing the next thing can kill demand for the thing you already have. The correct approach is the inverse: ship first. Build the thing, then speak about it. Every word you say will then be backed by something a person can actually run and experience. You're not asking for belief or faith; you're simply reporting a concrete fact. This fundamentally changes the game for how you share your journey with your audience.
