Why I'm writing in public

For six years, almost everything I've written has had an audience of about a dozen people. Design docs for the team. Code review comments. Incident writeups. The long Slack message that finally gets product, engineering, and compliance pointing the same direction. Some of the most useful thinking I've done lives in private repos and internal wikis where it helps exactly one company.

This blog is me fixing that.

Writing is not a side activity

Here is the thing I took embarrassingly long to learn: writing is not what you do after the engineering. It is part of the engineering.

The clearest example from my own work: I once found a compliance gap in how our platform handled protected health information, on a system that more than 200 medical practices depended on. Finding the gap was pattern matching. Fixing it without stopping the roadmap was mostly a writing problem: laying out the risk plainly enough that compliance, product, and the engineers shipping features that week could all see the same picture and agree on the same trade-offs. The re-architecture went through because the document did.

The moment you cannot explain a decision in plain words, you have found the part you do not actually understand. Reading the code back never tells you that. Writing does.

What to expect here

Working notes, mostly. The kind of thing I would put in a design doc or explain in a code review, written down where it might save someone else the detour. Concretely:

• Real-time and AI product plumbing. First up: revisiting how I picked the streaming protocol for Pagewise, my tool that streams AI summaries token by token, including where my earlier "fingers crossed" read on WebTransport got overtaken in March. Spoiler: the answer is older and more boring than you would guess, and that is a compliment.
• Shipping AI in regulated domains. I spent years leading a team building HIPAA-compliant healthcare software. "Just add AI" reads very differently when the data is protected health information.
• What AI actually costs. I've just started building Kenda, an AI FinOps platform, with my co-founder Sebastian Lujan. Watching teams discover their LLM bill at month-end never stops being painful, and for once I get to work on the fix from day one. Expect building-in-public notes.
• Performance and accessibility as features. Web Vitals, perf budgets in CI, and interfaces that work for everyone. A habit from years of building high-traffic interfaces, and one I intend to keep.

And what not to expect: hot takes, breathless AI announcements, or advice about tools I have not run in production. I try to be clear-eyed about when new tech actually helps and when a simpler thing is the better call. That rule applies to blog posts too.

On cadence, honestly

I am not going to promise a post every week, because that promise produces filler. The deal is simpler: when I ship something with a decision worth unpacking, or step on a rake worth flagging, I will write it down.

If something here is useful, wrong, or worth arguing about, tell me. The private version of this writing always got better when someone pushed back. I expect the public version works the same way.