How I think about software

I think about software the way I think about buildings: the foundation decides what's possible later, and it's the part no one sees when it's done right.

Before I write a line of code, I want to understand the constraint that actually matters — a regulation that can't be half-satisfied, a hardware limit that can't be wished away, a scale the business will hit if things go well. Everything else is negotiable. That constraint isn't.

I came to this from building for real businesses from the start. Early projects meant sitting with business owners — a construction company with thirty years of history, a family services business — and translating what they actually needed into something that worked, not into what looked good in a screenshot. That habit never left: I still start conversations by asking what the system needs to survive, not what it should look like.

Architecture is where I spend the time other people spend on features. A system's shape — how data flows, what's mutable, what's a service boundary — determines everything that's cheap or expensive to change six months in. I'd rather be slow here and fast everywhere else.

I build both sides — backend and frontend — because the seam between them is usually where the real product decisions live, and I don't want to hand that seam to someone who wasn't in the room for the constraint that shaped it.

The through-line across Veridico, SON Identity, and the automation systems I build is the same: take something operationally painful or legally rigid, understand exactly why it's hard, and design a system simple enough that the difficulty disappears for the person using it. Complexity is fine in the architecture. It's not allowed to leak into the interface.