Professional
I'm a technical operations and systems engineer focused on the judgment layer between infrastructure, security, automation, and day-to-day operations. I work best where systems have to be reliable, changes have to be defensible, and troubleshooting has to move from symptoms to root cause without losing sight of the people who depend on the result.
My experience spans Windows and Linux infrastructure, identity and access management, virtualization, networking, automation, and GMP-regulated systems. I tend to work across boundaries: understand the environment as a whole, decide what should be standardized or automated, and carry the work through implementation, documentation, and recovery planning.
I build for reliable operations rather than impressive demos. That means least privilege, explicit boundaries, recoverable designs, clear ownership, and enough documentation that the system can remain understandable months later and by someone other than the original implementer.
TekForge
TekForge is my working engineering environment and the public record of that practice. It includes infrastructure I actually rely on, tools I build to run parts of my life and work, and writeups that explain the decisions, tradeoffs, failures, and recoveries behind them.
TekForge is almost always under development, but it is not treated as one endless experiment. I establish stabilizing baselines, operate against them, and then change deliberately: one boundary, workflow, or capability at a time. Some components are mature and relied upon every day; others are active prototypes. I try to make that difference clear rather than presenting every build as equally finished.
Real systems rarely become finished. They become understood, supportable, and safe to evolve. TekForge is where I practice finding that balance between continuous development and operational stability.
The longer arc reaches beyond a homelab: using systems thinking to build more capable infrastructure, practical automation, independent work, and eventually a more self-sufficient physical environment. The goal is not technology for its own sake, but capability without hidden fragility.
For deeper technical walkthroughs, postmortems, and the longer version of how this work has evolved, see the Writing section.
Principles
Build for recovery, not just deployment.
Prefer clarity over cleverness.
Keep access intentional and boundaries explicit.
Document the work so it can be understood and repeated.
Design systems that stay maintainable as they grow.