On Building, Systems, and the Things Around Them
I've come to understand this space isn’t just about code.
For some time now, I've focused on building applications, APIs, dashboards, systems that solve problems and move data around. Real things, used by real people, running in environments where correctness and performance matter.
That work matters, and I still care deeply about it.
But over time, something else became harder to ignore.
Every system lives inside a larger system.
Infrastructure. Constraints. Failure. Time.
And beyond that, an even wider layer: the people using it, the expectations around it, the culture it’s built within, and the moment in history it belongs to.
Technology doesn’t exist in isolation. It reflects how we think, what we optimize for, and sometimes what we overlook.
This site is an attempt to work across those layers.
Part of it is concrete.
Designing systems with intention. Understanding infrastructure not as an afterthought, but as a foundation. Building things that don’t just work, but can be operated, observed, and recovered.
Because a system that works only under ideal conditions isn’t really working — it’s just untested.
More recently, that has meant shifting attention toward the platform itself:
- how systems boot and recover
- where data lives and why
- how failures are contained instead of spreading
- how to verify system state instead of assuming it
Small decisions at this level tend to compound.
They define whether a system degrades gracefully or fails unpredictably.
Another part is less defined.
It involves thinking about how AI is changing the way we build.
Not just in terms of speed, but in how it reshapes:
- how decisions are made
- how much we rely on generated solutions
- how knowledge is retained (or lost)
- where human judgment still matters
AI is a powerful accelerator, but it also introduces a subtle risk: moving faster without fully understanding the systems we’re building on top of.
So part of this space is about navigating that tension — using these tools without giving up ownership of the work.
And somewhere in between lies the craft itself.
Why we build the way we do. What we choose to simplify. What we choose to ignore.
What we optimize for — and what we accept as trade-offs.
Lately, I’ve been thinking less in terms of features, and more in terms of systems that can be trusted under pressure.
That shift is still ongoing.
I don’t plan to document everything.
Only what feels worth capturing:
- decisions that changed how I approach a problem
- patterns that hold up beyond a single project
- moments where something shifts in how I see the system as a whole
This will include some deeper dives over time — into infrastructure, failure domains, observability, and the practical side of operating systems beyond just building them.
But for now, this is the starting point and I'm glad you've made until here, it probably means you’re thinking about some of these things too.