IRS.gov is the largest public-sector financial UX surface in the United States. The Payments experience handles the actual collection: taxpayers funding the federal government one transaction at a time. Scale: 880.9 million visits in FY2023, $4.7 trillion in tax collection supported.
I led the engineering on modernized payment features: building new flows from scratch, leading more junior and mid-level engineers on the same work, helping the team adopt TypeScript mid-project, and pushing accessibility standards into every interaction. The challenge isn't novel architecture. It's that the system has to work for everyone, every time. Every income bracket, every accessibility profile, every device, every browser the federal government still has to support.
Accessibility: error-validation flow across the payment surface
Public-sector tax software runs into edge cases most product engineers never see. A taxpayer unable to complete a payment because of an unsurfaced validation error doesn't switch browsers; they call the IRS, or the payment doesn't go through. Every error had to be recoverable, announceable, and obviously locatable.
The error-validation pattern across the payment flow:
- On-click validation at submit / next. When the user attempts to advance, the page runs full validation across every field, gathering errors simultaneously rather than failing on the first one.
- Top-of-page error summary. A bulleted list of every error that occurred on the page, so screen-reader users hear the full scope of what needs fixing in one announcement instead of discovering errors field by field.
- On-blur validation per field thereafter. Once errors are surfaced, each field validates as the user leaves it, giving immediate feedback without requiring a re-submit. The cycle continues until the page is clean and the user advances.
All of this implemented against strict WCAG standards.
Leading new features end-to-end
I led the engineering for new payment-experience features that didn't exist in the legacy system: modern mobile-friendly tax payment flows, pre-paying taxes, and other interactions taxpayers expect from any payments product in the current era. Each feature was built from scratch rather than retrofitted onto the legacy markup.
That work included leading junior and mid-level engineers building alongside me, pairing on technical direction and owning the shipping cadence end-to-end.
TypeScript adoption mid-project
Mid-project the team pivoted from JavaScript to TypeScript. I helped lead that transition: bringing the team along on the new layer of type safety, and through the early-adoption stage where TypeScript can feel like friction before it starts catching the bugs it's meant to catch.
Beyond the language switch, I focused on maintainability through code review:
- Adapting feedback style to the engineer. Some teammates wanted rigorous nit-level comments, some wanted high-level direction, some wanted to pair through it. Reviews landed differently when matched to how the recipient processed feedback.
- Reviewing for the next maintainer, not just the immediate change. Leaving the codebase in a state the next engineer to touch it could understand without archaeology.
The trade-offs
Engineering at this scale stops being about clever architecture. It's about staying boring on purpose, surfacing failure modes early, and writing code the next engineer can read without regret. The frontend at IRS isn't where the heavy security or PII handling lives (that's the backend's job) but at 880M visits a year, it's the surface every taxpayer touches, and its failure modes are visible to every one of them.