Digital Commerce
The patient-facing commerce program for a $4B healthcare organization — where booking an appointment is the storefront, and identity is the checkout.
Healthcare's front door is digital now: patients discover, book, check in, and pay online — or they go somewhere else. This is a multi-year program, built in chapters: first re-platforming five consumer brands onto a shared-package architecture, then fraud detection for fake appointments, intelligent scheduling, CMS 2.0 for marketing pages — and now a real identity platform that billing and treatment features can be built on.
shared platform
across 48 states
one architecture
center, online, in-office
A multi-brand Next.js platform.
What is the multi-brand Next.js platform?
The patient-facing web platform for five consumer brands of a $4B healthcare group, with 1,400+ locations across 48 states. It replaced six legacy stacks with one monorepo: brand schedulers, marketing sites and office directories are Next.js applications built from the same shared packages, behind a single GraphQL gateway. Fraud detection, MCP servers that let ChatGPT and Claude book appointments, intelligent scheduling, CMS 2.0 and the identity platform all build on it.
How do five brands share one Next.js codebase?
By sharing packages, not applications. The first consolidation put the brands into shared apps: 80% of the code was shared, but every deploy, merge and performance budget was coupled too. The second era gives each brand its own Next.js App Router application built from the shared packages, so 60–80% of the code is still shared and each brand deploys on its own.
What runs behind the Next.js apps?
A single GraphQL gateway stitches the downstream subgraphs and REST sources, with Redis caching to keep it fast, and an MCP server exposes tools to AI agents. The apps run on Kubernetes behind per-brand CDN distributions, with feature flags at the edge so every cutover can be rolled back. The native apps follow the same pattern through Flutter flavors.
Healthcare is a commerce business that books time.
Strip away the clinical vocabulary and a patient journey looks like commerce: discover a provider, book a slot, identify yourself, manage the relationship, and pay. Patients expect that journey to work the way the rest of their digital life does — 80% want to handle scheduling digitally, anytime — and they act on friction by going elsewhere.
At a $4B healthcare organization, that journey had grown up in pieces. Appointments were created through at least four channels — an AI chat assistant, the call center, an online scheduler, and local offices — while the patient portal sat beside them for matching patients to existing appointments, confirming, and rescheduling. Each piece worked. The spine connecting them didn't exist.
Built in chapters, each unlocking the next.
This wasn't one project — it's a platform program that has moved through six chapters, each standing on the one before it:
A storefront with no checkout.
By the current chapter, the storefront was in good shape — re-platformed, defended against fake bookings, smarter about slots, and faster to market. The deepest remaining problem wasn't any single channel — it was that the platform had no trustworthy answer to "who is this patient?":
Fix the spine, keep the estate.
The bet: treat the patient journey as one commerce spine — booking, identity, portal, billing — and invest in platform primitives instead of page rewrites. Buy the commodity layers (Auth0 for identity, Twilio Verify for MFA delivery) and spend engineering only where the domain is genuinely unusual: linking accounts to the right patient records, caretaker relationships, and claim compatibility with the existing estate.
The keystone was identity. Email became the unique account identifier, email and phone are verified during signup, and custom claims (Patient Identifier A, B, and C) ride the access token — so every existing microservice accepts the new tokens by validating a JWT and reading the same identifiers it always used. The portal itself was rebuilt from Next.js 14 Pages Router to Next.js 16 with the App Router — Server Components, streaming, route-level code splitting — so the first thing patients meet after their first real login is also a faster product.
Four ways in, one spine underneath.
Booking channels and patient clients converge on a shared GraphQL layer and microservice estate, with the Auth0 tenant issuing claims-bearing tokens beside it.
The commerce spine, piece by piece.
Identity platform
Auth0 accounts with verified email + phone, a menu of MFA factors from SMS to passkeys, and patient linking that survives sessions.
Portal redesign
The patient portal rebuilt on Next.js 16 + App Router — a UI redesign shipped with the identity cutover for one visible upgrade.
Appointment management
Matching patients to appointments booked in any channel — view, confirm, cancel, reschedule — plus scoped one-click links from email.
Pre-visit workflows
Check-in forms, insurance updates, and address changes — writes that now land on a verified identity.
Call-center console
Support staff handle routine account tasks through a delegated console — same-call resolution instead of engineering tickets.
What it changed in the first month.
The platform launched in September 2026. These are first-month numbers from the Auth0 logs and web analytics, rounded down, next to what the architecture guarantees by construction.
More than 8 in 10 people who started sign-up finished it, and over a third of MFA enrollments chose a passkey. The rebuilt portal is faster too: mobile LCP improved by about a third, and sessions ending on an error page fell by more than two thirds.
The honest cost is the extra step. Fewer email links reach their destination now that sign-in sits in front of them, and the record-match check at signup turns some real patients away. Tuning that funnel is the current work.
And the number that mattered most inside the building: the coordination footprint. Identity touches everything, so everyone touches identity.
Infra · QA · UX
engineering
frontend + backend
Budget for the coordination the way you budget for the code: it's not overhead around the real work, it is the real work.
In healthcare, identity is the commerce platform.
Every commerce platform has a moment where the anonymous visitor becomes a known customer, and everything of value happens after it. Healthcare compresses all of its regulatory, revenue, and safety stakes into that one moment: get identity wrong and you can't bill, can't show treatment data, and risk writing to the wrong human's record. Get it right and the rest of the funnel is "just" product work.
The engineering lesson was about leverage: buy the commodity, build the domain, and never break the estate. Claims-compatible tokens let more than eight services adopt a new identity platform without a rewrite — and that compatibility trick, more than any single feature, is what made the whole commerce spine shippable.
The platform, in more depth.
See all five case studies.
A platform like this is a team sport. Some of the engineers behind it write about their work too — go read them: Vinay Bandi · Sreeram Ganesan.
This case study is written in a personal capacity and reflects my own perspective on the work; it is not affiliated with or endorsed by my employer. Some details are simplified, generalized, or anonymized, and figures describe the platform at the time of writing. All trademarks belong to their respective owners.