Wameedh Mohammed Ali
Case study · LVIS

Modernizing the LVIS platform

A 200-component Vue 2 to Vue 3 migration, a real-time notification protocol, and billing automation, on a clinical data platform.

Role
Senior Frontend Engineer
When
March 2022 to September 2024
Stack
Vue 3, TypeScript, TanStack Query, WebSockets, PHP, Stripe, WebGL
Result
−20% load time

The problem

LVIS builds software for clinicians who review EEG data. The web platform had grown on Vue 2 for years. It had more than 200 components, state management that had drifted, and a notification system that could not be trusted to deliver an alert on time. The team was spending more time working around the codebase than building in it.

What I did

Led the Vue 2 to Vue 3 migration. I planned the sequence, adopted the Composition API to simplify the most tangled components, and refactored more than 200 components to use Vue 3 features. Server state moved to TanStack Query, which removed a large amount of hand-written caching. I wrote the migration documentation so the rest of the team could follow the same patterns.

Designed real-time notifications. Together with the backend team I architected a WebSocket-driven notification system and designed the communication protocol from scratch. Alerts for critical events now arrive near instantly instead of on the next poll.

Automated onboarding and billing. I engineered a PHP backend service that automates dynamic billing through the Stripe API and streamlines onboarding for new users. Manual adjustments went away, along with the errors they introduced.

Built for the data. I developed a WebGL-compatible data layer for a 3D EEG visualization engine, which cut diagnostic review time for clinicians by 80 percent.

Raised the floor on quality. I added comprehensive unit tests, reached 90 percent coverage on the project, and introduced test-driven practices to the team.

What made it hard

A migration of this size cannot stop feature work. The order of operations mattered more than any single refactor: which components to move first, how to run both APIs side by side, and how to keep the test suite green through every step. The notification protocol had a different constraint. In a clinical setting a late alert is worse than no alert, so correctness came before cleverness.

Result

Load times dropped by 20 percent and the codebase became something the team could extend again. Notifications became reliable. Billing stopped needing hands. Diagnostic review in the 3D viewer got 80 percent faster.

Looking back

Two things I would do differently. I would instrument the migration from the first week, with a simple count of components on the new API over time, so progress was visible to the team and to leadership without anyone asking. And I would have pushed to design the notification protocol before the first feature that needed it, instead of retrofitting reliability into a system people already depended on. Both are the same lesson: make the invisible work visible early, and build the hard guarantee before the first customer of it arrives.