Leading ABB Verify modernization while weekly releases kept moving
I led modernization work across a 150K+ LOC React SaaS while requirements changed, business-facing features shipped weekly and technical debt still had to be handled.
React tech lead, senior web developer
front-end architecture, UI systems, product delivery
SaaS for US eye-care providers
weekly release cycle
I led modernization of a 150K+ LOC React SaaS while juggling shifting requirements, weekly product delivery and technical debt.
Frontend architecture, UI systems, typed data flows and product-facing delivery.
The work made future product changes safer to build, review, iterate on and keep current.
This page goes deeper, but that is the story I want a recruiter, client or product leader to remember.
Public sources are used for product context. Private screens, exact architecture and business metrics stay abstracted.
What ABB Verify does
ABB Verify sits between practice-management systems and payer portals, giving eye-care providers one place to work with insurance checks, benefits, messaging and appointment context.
Practice and payer data
practice-management integrations
patient and appointment context
authorized payer portals
ABB Verify
ahead-of-time checks
real-time searches
benefits messaging
Practice action
prepared appointments
coverage result cards
unused-benefits outreach
Insurance checking engine
The core capability combines practice-management context with authorized payer-portal checks for appointment prep, unused-benefits messaging and real-time patient searches.
Patient messaging and unused-benefits workflows
Automated outreach helps practices turn available benefits into scheduled patient actions.
Appointment-related operational screens
Daily work happens in dense views with patient context, scheduled visits and action-heavy data.
Reporting and practice-management integrations
The product connects with practice systems and turns operational activity into clearer reporting.
The work I led
This is the short list I would want a recruiter, client or product leader to remember before the implementation details.
This was not just an updated-libraries project. Technical cleanup became a way to make product work safer, clearer and easier to continue.
Active SaaS modernization
Led modernization of a 150K+ LOC React product away from legacy CRA and scattered Bootstrap-era foundations without stopping weekly delivery.
Branded UI foundation
Led the consolidation of Bootstrap, SCSS and CSS modules into a Material UI (MUI) foundation that felt closer to one ABB product.
Typed API layer
Introduced RTK Query and generated clients from multiple OpenAPI schemas so product work had safer data contracts.
Onboarding portal
Led the design and implementation of a resumable multi-step signup flow with integrations.
Dense operational UI
Worked on data-heavy screens with large tables, nested data, pagination, filtering and virtualization where it mattered.
Export tooling
Led the move to a monorepo shape, shared duplicated generator logic and introduced parallel generation.
The problem was not a rewrite
The real project was the juggling act: changing business requirements, weekly feature delivery and technical debt all moving at once.
When I joined, the main front-end was a large Create React App codebase with old React patterns, several styling systems, Redux thunks, connector HOCs, class-based forms and weak TypeScript in important areas.
The harder part was that none of this existed in isolation. Requirements could change even mid-sprint, but the app still supported real users, weekly releases and a product roadmap. I led the modernization in slices the team could actually ship.
This is the project where my work started to feel less like frontend execution and more like product engineering. I had to understand why a workflow existed, how staff used it and what kind of technical change would survive contact with the next release.
Balance delivery and debt in slices people can ship.
My job was not to sell a rewrite. I led the work by finding places where the team could replace legacy foundations while still delivering visible product work.
Modernization work
The core work was not about chasing a newer stack. It was about changing the default path for future product work.
Create React App
Vite
Bootstrap, SCSS, CSS modules
Material UI (MUI)
Redux thunks, connector HOCs
Redux Toolkit, RTK Query
Class forms, validate.js
React Hook Form, Zod
Manual request typing
Generated clients from OpenAPI
UI foundation
Several Bootstrap layers, SCSS modules, direct CSS imports and inconsistent UI patterns.
A cleaner MUI-based interface foundation aligned closer to ABB branding.
State and data
Redux reducers, thunks, connector HOCs and request logic spread through components.
Redux Toolkit, RTK Query and generated typed API clients from OpenAPI schemas, making contract mismatches visible instead of hidden in manual request code.
Forms
Class-only form components, inheritance-heavy abstractions and validate.js rules.
React Hook Form and Zod for more explicit, modern and reusable form flows.
Tooling
Create React App, heavy dependencies and modules that added avoidable build footprint.
Vite-based tooling, modern libraries and a stack that is easier to keep current.
Product work behind the stack work
Private app screens stay private, so these simplified artifacts show the workflows around the engineering story.
Insurance checking is the product's main workhorse.
ABB Verify combines practice-management data with authorized payer-portal checks ahead of time for scheduled appointment preparation and unused-benefits messaging. Real-time search is another mode of the same capability: staff can run a patient lookup and get structured result cards for vision benefits, authorizations, second-pair opportunities, partial matches and medical eligibility.
This is public product context. My work on the real-time result surface was mostly visual polish, but insurance checking matters because it explains the daily value of the platform.
C. Gutierrez · vision + medical
payer results + match clues
VSP
2 plansSecond Pair Opportunity found!
VSP Choice Plan
Exam
Frame
Lens
CL
CL Exam
VSP Diabetic Eyecare Plus Program
Exam
Frame
Lens
CL
Medical
86% patient match
Review the differences, then confirm to show this plan as a found result.
name:
Chris / Christopher
address:
12 Elm / 42 Oak
DOB:
exact match
TriZetto
UMR-Wausau
Met ded.
$50 copay
Unused benefit found. Schedule here:
rivera.care/schedule
Thanks, Dr. Rivera. I scheduled my appointment.
Benefits messaging
A public product pillar translated into patient-friendly outreach and staff-visible activity.
Generated summary
patients
benefits
messages
Monthly exports
The generated summaries and internal export tools are shown as a workflow, not as private implementation detail.
Onboarding journey
account
completed or resumable
practice
completed or resumable
agreement
completed or resumable
payment
external step
handoff
external step
Onboarding portal
A resumable signup path with authentication and third-party steps made legible as a product journey.
How I lead the work
A lot of the role is translation: from ambiguous and changing requirements to technical plans, from technical debt to business tradeoffs.
I try to understand the domain deeply enough to challenge the problem, not only implement the requested screen. That means asking why a workflow exists, where the business pressure comes from and what kind of solution will still make sense after the first release.
The UI was often the visible edge of deeper business workflows: backend-heavy operations, database-driven processes and internal management screens. My front-end role was to make those workflows usable, reviewable and safe for staff while staying close to the product and backend decisions behind them.
What became easier to ship
The point was not to pause the roadmap for cleanup. It was to improve the foundations while business requirements changed, real features shipped and technical debt still needed attention.
I led the main front-end away from CRA and Bootstrap-era foundations toward Vite, MUI, RTK Query and typed OpenAPI clients.
I replaced fragile request and form patterns with safer defaults in the areas I modernized: generated clients, React Hook Form and Zod.
Iteration got faster because common UI, form and API work moved onto reusable rails: MUI for interface patterns, React Hook Form and Zod for forms and generated RTK Query clients for typed requests, caching and refetching.
I designed and built product-facing surfaces where business process mattered: onboarding, dense operational views and export tooling.
I led changes that made the product feel less like several UI generations stitched together and more like one ABB platform.
Good front-end leadership is product leadership with a compiler attached
ABB Verify is the project that best explains how I want to work: close to the user interface, honest about technical debt and increasingly involved in the product and business context behind the code.