I started in 2011 with a Sitecore handbook, a copy of Visual Studio 2010, and a contract to help build the Institute of Defense Analysis's first Sitecore platform. They issued me a security clearance. I issued myself a crash course in web.config transforms. And I spent the next three years figuring out how to make a content management system carry workloads it was never quite designed for.
That has been the pattern of my career.
The years
The work moved through industries but kept the same shape: a complex enterprise needs a digital surface that actually works, and someone has to make all the moving parts hold together.
In the years since, I've architected and led implementations across:
- Government — the Institute of Defense Analysis, Denton County, and most recently the California State Lottery, where I'm now Group Technical Lead at ICF Next.
- Industrial and consumer brands — HB Fuller's multilingual platform via Lionbridge, General Mills' family of brand sites, MCFA's dealer-facing product API, MHC Trucking's mobile + Sitecore integration, Toro's voice-experience POC.
- Healthcare and civic — the University of Kansas Hospital's intranet and physician sync layer, St. Louis Public Library's CMS migration.
- Energy and finance — Dominion Energy's full redesign, Promontory Interfinancial's multi-site Umbraco architecture.
In 2019, my twin brother Dakota and I founded TwofoldTech LLC. The same year I picked up a multi-year stint at Aware Web Solutions. In 2022 I stepped into the Group Technical Lead role at ICF Next, where I now run development, infrastructure, security, and QA for a platform that moves millions of transactions a day under accessibility, regulatory, and audit constraints that don't blink.
Different domains. Same job: take a system other people depend on, and make it not break.
What the work taught me
A few things that don't show up on a résumé:
- Reliability is a moat. When the lottery draws happen, registration works, and the API stays up under load, nobody notices. That invisibility is the product.
- Complexity compounds. Every integration is a new failure mode. Every migration breaks something. Every accessibility audit finds something. The discipline that keeps these systems alive is unglamorous and underrated.
- The expensive skill is judgment. Knowing which corner to cut, which warning to escalate, and which fight to pick at a code review is what separates a senior engineer from a force multiplier.
This is the foundation. AI sits on top of it.
Why AI, why now
I didn't drift into AI because the headlines pulled me in. I started building AI-native products because I kept running into the same realization in the day job: the next layer of these enterprise systems is going to reason about itself.
The lottery platform has dashboards. Soon those dashboards will explain themselves. The Program Increment planning artifacts I work with are spreadsheets full of resource hours; soon those spreadsheets will flag risk before the meeting starts. The Application Insights logs that wake people up at 3 AM have patterns buried in them; soon those patterns will surface themselves.
That's what we're building now, through TwofoldTech:
- TwoOps — an AI-native infrastructure operations platform for Azure. Auto-discovers resources, scores their health, runs Claude-driven root-cause analysis, and surfaces patterns humans don't have time to spot.
- PI Strategist — Program Increment planning analysis with Claude as an embedded SAFe advisor.
- Pulse — browser-only triage for Azure Application Insights logs with five AI analysis modes.
- LoadBridge — load-test orchestration for JMeter and k6, with automated bottleneck detection.
- Twofold Lead Engine — an autonomous multi-source pipeline that powers our own outreach.
None of these are AI demos. They're production engineering with reasoning embedded in the right places.
The through-line
The skills that made me good at keeping a Sitecore platform alive for millions of users are the same skills that make AI-native software not embarrassing.
Knowing where the brittle parts are. Knowing what "good enough" means, and where it stops applying. Knowing how to wire a new capability into an existing system without burning down the existing system.
LLMs are a new substrate. They aren't replacing the work — they're sitting on top of it. And the engineers who understand both the old layer and the new one are the ones who get to build the next decade of software.
That's the bet. We'll see.