I make complicated software simple.
I'm a senior frontend engineer who came up through design. I take product problems from “what should this be?” to a shipped, tested interface on an architecture other engineers can live with.
Open to senior frontend and frontend architecture roles: remote, or hybrid in Cincinnati.
Download résumé (PDF)Now
Senior Software Engineer
- Leading frontend architecture for healthcare products
- A configurable pharmacy platform in Next.js, React, and GraphQL
- Accessibility, automated testing, and standards for AI-assisted development
Twenty years of experience, from design and consulting to enterprise UI at Ingage, Kroger, CBTS, and Trivantis.
Architecture
Three pharmacy brands. One codebase. No forks.
Every new brand brought requirements of its own: the kind that usually splits a product into separate apps. I built the multi-brand system that lets them all run on one shared core, with configuration and a few per-brand components carrying the differences.
- Next.js
- React
- GraphQL
- Zustand
- MUI
PharmcoRx
added with a config file, env files, and build scripts, then given its own fonts, colors, and corners while the other two kept their existing theme exactly.
Three brands
Three brand sites. Two share a typeface and square corners; the third has its own typefaces, pill buttons and rounder corners. Each has its own colors, and each switches the same 18 feature flags on or off differently.
What each brand's config carries
- Colors
- Typefaces
- Corner radius
- 18 feature flags
- Logos and copy
One shared codebase
Every form and checkout step. Seven components pick a per-brand version; the other ~270 are shared.
Product and UX
A partner portal, shaped before it was built.
Pharmacy partners ran orders, reports, and API changes through email and engineers. I wrote the pitch for a self-service portal, reviewed it with frontend and backend engineers, and am building it, with the UX decided around the operations staff who'll use it.
- Product shaping
- UX
- Next.js
- TypeScript
- GraphQL
Labeled filters
chosen over a search box with chips, because of who uses it.
9 areas
with working screens so far. Still in progress.
Before
Every request, one inbox
- Look up an order
- Correct a patient record
- Pull a report
- Rotate an API key
All by email, each waiting on an engineer.
Shaped
A written pitch
- The problem
- A solution for each area
- Rabbit holes
- Out of scope
Built
Working screens
Labeled filters, and records that open over the list.
Quality
Accessibility issues, fixed and re-checked.
Audits kept finding problems: forms that failed silently for screen readers, controls a keyboard couldn't operate, dialogs nested inside dialogs. I fixed most of them on the way to a third-party accessibility seal on HealthWarehouse, then wrote the automated tests that re-check it.
- WCAG 2.2
- Playwright
- axe-core
- Screen readers
Announced
Form errors and confirmations now reach screen readers across checkout, payments, and account forms.
40+ routes
re-checked by axe-core in five browser and device profiles.
Found
Audits and screen-reader testing
Fixed
Forms, keyboard, dialogs
Verified
WCAG 2.2 accessibility seal
Re-checked
Automated tests, run by hand
How this happened
Different rooms, same habit.
Design, development, consulting, architecture: in every role, I notice how something gets used, then build toward that instead of around it.
AI in practice
AI helps write the code. I protect the rules it follows.
This site's own repository runs Claude Code with hooks that flag every change to the agent's rules for my review.
- .claude/settings.json
- .claude/hooks/*.sh
- CLAUDE.md
- AGENTS.md