Architecture decisions
Why a schema, boundary or rendering strategy was chosen, what it cost, and what I would do differently next time.
Engineering journal
Blog
Post-mortems, architecture decisions and the lessons that only show up after a system meets real users.
Editorial focus
What I write about
These are working notes from real builds, not tutorials assembled after the fact. The useful parts are usually the constraints and the mistakes.
Post-mortems
The failure, the fix and the change that followed. Written close to the incident, with the parts that were uncomfortable left in.
Auth and security
Sessions, OTP flows, permission boundaries and the small implementation details that decide whether a system is actually protected.
Performance
Query plans, caching, bundle weight and Core Web Vitals — measured before and after, not asserted from a best-practice list.
How a post is put together
The context: what the system was doing and what constraint mattered.
The failure or decision: the symptom, the trade-off and the options considered.
The fix: what changed in the code, data or process.
The transferable lesson: what I would apply to the next system.
