I'm a senior software engineer and architect who spends most of my time on systems that sit at the center of a business — the platforms finance, sales, and operations teams depend on every day. My work spans full-stack engineering, cloud architecture, and, more recently, AI systems that reason across an entire business rather than a single feature.

I care most about the layer where technical decisions become business outcomes: how a data model shapes what a company can report on, how a permissions design determines what an AI assistant is allowed to see, how a deployment strategy affects how confidently a team can ship. That's the work I enjoy most, and the reason I've moved from feature delivery into architecture and technical leadership over the course of my career.

How I think as an engineer

I start from the business problem, not the technology. Before proposing an architecture, I want to understand what the system needs to be true in a year — how many tenants, what compliance requirements, what happens when a module needs to change independently of the others. Decisions that are cheap to reverse (a button placement, a component structure) I move fast on. Decisions that are expensive to reverse (a data model, a tenancy boundary, a permissions design) I slow down for.

What problems I enjoy solving

Systems where multiple domains have to work together without becoming tangled — a CRM that shares data with dispatch, a payroll system that has to be both flexible and audit-proof, an AI layer that has to reason across modules without bypassing the permissions each of them enforces. The common thread is designing boundaries: what belongs together, what needs to stay separate, and how information should flow between the two.