Engineering
Software that keeps its promises
I've spent my career learning the difference between software that demos well and software that survives production. This section is about that difference: architecture, correctness, and the unglamorous details that decide whether users trust you.
A lot of it comes from fintech, where the bugs are other people's money. Those habits — ledgers, idempotency, reconciliation, explicit state — turn out to make every kind of software better.
Where to start
Production is a promise
Error handling, migrations, monitoring — the parts that don't demo are the parts that matter. Start with the failure modes, not the happy path.
Boring infrastructure, exciting product
PostgreSQL, typed languages, explicit state machines. Save your innovation budget for the product, not the plumbing.
Correctness is cultural
Tools don't make systems correct — habits do. Reviews, tests, and standards that survive deadline pressure.
Latest on this
All writing →Articles on this topic are in the queue. They land in The Build Log first, then here.
The stuff I learn while building.
I test a lot of tools, workflows, and ideas. The Build Log is where I share what actually worked, what surprised me, and what I would do differently.
AI workflows. Claude. Agents. Building software. Building companies.
- Practical AI workflows I actually use
- Tools and systems worth your attention
- Lessons from building software and companies
- Things I learned the hard way
One email when there is something worth sharing. From Charles, no one else.
