All writing

The Quiet Case for Building in Public

Sharing work before it is finished feels risky. It is also the fastest way I know to get better.

There is a specific fear that shows up the moment before you publish something unfinished: what if it’s wrong? The instinct is to wait — to polish until the work is unimpeachable. I’ve come to believe that instinct is mostly a trap.

Feedback beats polish

A finished thing can only be judged. An unfinished thing can be improved. When you share early, you trade the comfort of privacy for something far more valuable: other people’s eyes on the problem while it’s still soft enough to change.

The math is simple:

  1. Ship a rough version.
  2. Watch where people get confused.
  3. Fix exactly that.
  4. Repeat.

Each loop is cheap. The alternative — perfecting in isolation — front-loads all the cost and delays all the learning.

A small example

Here’s a helper I published half-finished last month. A reader pointed out it broke on empty input within the hour:

function slugify(input: string): string {
  return input
    .toLowerCase()
    .trim()
    .replace(/[^a-z0-9]+/g, '-')
    .replace(/^-+|-+$/g, '');
}

That fix took thirty seconds. Finding it alone might have taken weeks — or never.

The compounding part

Building in public isn’t only about bug reports. Over time it builds something quieter and more durable: a body of work that speaks for you. People don’t follow a single post. They follow a trajectory.

You can’t reverse-engineer trust. You can only accumulate it, one honest post at a time.

Start before you’re ready. That’s the whole trick.