Building in the open

“Build in public” gets thrown around as a growth tactic, but I mean something narrower and less glamorous: the source is public, the plan is public, and when I get something wrong, the fix is in the history for anyone to read. This is a short note on why I keep working that way and what it costs.

The discipline tax

Working in the open imposes a tax, and that’s the point. When a stranger can read your commits, you stop writing commit messages like fix stuff. When the spec is a file in the repo rather than a vibe in your head, you have to actually decide what “done” means before you start. When the CI gate is visible, a red build is a public red build, so you fix the gate instead of disabling it.

None of that is free. It’s slower in the moment. But it front-loads the thinking, and front-loaded thinking is the cheapest thinking there is.

What you get back

A few things compound over time:

• A paper trail. Six months from now I won’t remember why the CSP has a scoped exception for one path. The comment next to it — and the commit that added it — will.
• Fewer sacred cows. Code you expect others to read is code you’re willing to delete. Public work is easier to throw away because you never pretended it was precious.
• Honest estimates. It’s hard to fool yourself about progress when the plan has checkboxes and the checkboxes are in version control.

The mistakes stay in

The part people skip is leaving the mistakes visible. It’s tempting to rebase history into a tidy story where every decision was correct the first time. I don’t, mostly because the wrong turns are the useful part. The commit where I tried to inline a font and the CSP font-src 'self' policy rejected it taught me more than the one where it finally worked.

A small example

This site is the working example. The spec lives in docs/, each feature is a numbered plan with explicit acceptance criteria, and the verification gate — lint, types, tests, accessibility, performance budget — runs on every change. The blog you’re reading is itself a plan that got executed: Medium-style cards, reading time, structured data, and dynamic share images, built against a checklist and merged only when it was green.

That’s the whole pitch. Not transparency as performance — transparency as a forcing function for doing the work properly. The audience is mostly future me, and future me is a demanding reader.