Lead Software Engineer | Frontend Architecture | Technical Leadership
I lead frontend architecture for complex customer-facing React and TypeScript products, carrying product decisions across APIs, testing, accessibility, security, and production delivery. I focus on making complex behavior understandable, keeping system boundaries explicit, and leaving evidence that the result works.
Selected outcomes from my State Farm tenure include:
- Architected and built two customer-facing applications from the ground up.
- Led transaction workflows that supported 1,404 submissions across 1,174 policies during a measured 30-day production period.
- Built the primary application's TypeScript testing capability from zero to 131 test files and 2,197 passing tests.
- Established roughly 40 shared modules supporting more than 90 source and test files across two applications.
- Improved delivery through runtime-image optimization, vulnerability remediation, deployment visibility, code reviews, documentation, and mentoring.
My background spans geospatial data quality for Google Maps, ten years in data and analytics at Microsoft, open-source software engineering at WattTime, and customer-facing product engineering at State Farm. That progression shapes how I connect architecture to user behavior, operational context, and measurable business outcomes.
Today I lead frontend architecture and full-stack delivery for complex workflows, support engineers through design and review, and improve the systems and practices that make change safer.
Pay Period Planner is an independently built household cash-flow product that makes complex planning rules explicit, from accessible React workflows to versioned PostgreSQL ownership and cross-layer verification. It uses synthetic household records and contains no employer code, data, or implementation details.
React 19 | TypeScript | Redux Toolkit | Spring Boot | PostgreSQL | Flyway
- One canonical frontend draft and one version-checked mutation boundary
- Database-backed sessions, CSRF protection, and workspace ownership isolation
- Unit, controller, PostgreSQL integration, browser, accessibility, responsive, CodeQL, dependency, and Snyk verification
- Architecture decisions, known limitations, and a reproducible synthetic portfolio walkthrough
Portfolio case study | Source | Architecture | Engineering evidence
- Clarify the product: turn ambiguous requirements into explicit behavior and testable outcomes.
- Design the boundaries: keep state, domain rules, API contracts, and data ownership understandable across the stack.
- Build confidence: combine testing, accessibility, security, documentation, reviews, and mentoring so teams can deliver reliably.
- Connect decisions to outcomes: use product context and data to make tradeoffs visible and measure whether the result works.
Explore the portfolio for selected work, architecture decisions, and engineering evidence.