On building in public
The tension between shipping and explaining. Why writing about what you build makes you build better — and the habits that actually stick.
There’s a version of “building in public” that’s just marketing dressed up as vulnerability. Daily tweets about your MRR. Threads about your “lessons learned” that are really just acquisition funnels.
That’s not what I’m interested in.
What I’m interested in is the slower, messier version — writing to think, not writing to perform. Documenting the actual decisions, not just the ones that look good in retrospect.
Why write at all
I build things that most people won’t use. That’s fine. The audience for deep technical writing about AI agents, game engines, and personal infrastructure is small and specific — and that’s exactly who I want to reach.
Writing forces precision. You can be vague in your head. You can’t be vague in a sentence.
When I write about a system I built, I almost always find the hole in my reasoning. Not because readers point it out — because the act of explaining it forces me to confront what I don’t actually understand.
The habit problem
Most “build in public” advice assumes consistency is easy if you care enough. It’s not.
The real constraint isn’t motivation. It’s friction. If publishing a post requires ten steps, you’ll skip it when you’re tired. If it requires two steps, you’ll do it.
This blog is an experiment in reducing that friction to near zero: write in markdown, push to git, done. No CMS, no editor login, no publishing queue.
We’ll see if it works.
What this blog actually is
A record of things I figured out. Sometimes technical, sometimes not. Mostly about the intersection of software, systems thinking, and building things that matter to me.
No newsletter. No comments section. Just posts.
If something here is useful to you, that’s a bonus — not the goal.