Building in Public

Thoughts on sharing progress, getting feedback, and shipping things that actually matter — rather than polishing in a drawer for six months and then discovering nobody wanted it.

Why bother

Working in the open costs something. Every half-finished idea is visible, and the failures are as legible as the wins. That’s the point. A project nobody watches is a project with no deadline, and a project with no deadline tends to become a project with no ending.

The three things that made it worth it for me:

• Feedback arrives while it’s still cheap to act on.
• Writing the thing down forces the design to be coherent.
• Other people’s half-finished work is how I learned most of what I know.

What this looks like in practice

Small, frequent, unglamorous updates. Not launches.

Ship the boring version first. The interesting version is a refactor away, and the boring version is the one that tells you whether anyone cares.

Here’s the whole publishing pipeline for this site:

nix develop            # hugo, pinned
hugo server -D         # write, watch it reload
git commit && git push # actions builds and deploys

That’s deliberately unimpressive. Anything more elaborate becomes a reason not to post.

On tooling

A static site generator is the correct amount of technology for a personal site. The moment you need a database to publish a paragraph, the friction wins and you stop writing.

Use hugo new content posts/whatever.md and get on with it.

The uncomfortable part

Building in public means publishing things you’ll disagree with later. I’ve made peace with that. The archive is a record of what I thought at the time, not a claim about what’s true forever.

That’s the deal. It’s a good deal.