← All case studies
Case Study 01 Healthcare · Patient Experience

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.

Role
Principal Engineer — Web platform
Org
$4B healthcare organization
Timeline
3+ years · ongoing
Stack
Next.js 16 · GraphQL · Microservices
Identity
Auth0 · Twilio Verify MFA
5
consumer brands on one
shared platform
1,400+
physical locations
across 48 states
6→1
legacy stacks unified into
one architecture
4+
booking channels: AI chat, call
center, online, in-office
00 — In short

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.

01 — Context

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.

02 — The program

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:

01
Re-platform: share packages, not applications
Six legacy stacks unified into one shared-package monorepo — per-brand schedulers, marketing, and directory apps built from the same packages behind a GraphQL orchestration layer. Full write-up: Share Packages, Not Applications.
02
Fraud Detection — launched December 2025
Solving the fake-appointment problem — keeping bots and bad actors out of the booking funnel.
03
MCP servers for AI assistants — launched December 2025
Two brand scheduling MCP servers that ChatGPT and Claude connect to, so patients can find a nearby location, see open time slots and book a new appointment from inside the assistant they already use.
04
Intelligent Scheduling — launched early 2026
Getting smart about slots for each brand — slot inventory and availability tuned to how every brand actually books, instead of one-size-fits-all.
05
CMS 2.0 — launched March 2026
Driving better marketing landing pages by decoupling content from presentation. The legacy CMS space had crept to 147 content types — three shy of the platform's 150 ceiling — because every new design needed new types and a developer. CMS 2.0 gives each brand its own space and composes layouts from fewer than 15 core types, so brand teams ship new landing pages with no new content types, no new components, and no developer in the loop. Staff engineer Vinay Bandi led this effort and wrote up the architecture in his case study.
06
Identity Platform — launched September 2026
Real accounts, verified contact data, and MFA via Auth0 + Twilio — the chapter the rest of this case study zooms into, because it's the one that unlocks commerce itself.
03 — The challenge

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?":

01
No real accounts
The portal had no sign-up, no passwords, no MFA — only emailed magic links riding the marketing pipeline (delayed 5+ minutes at times) and a demographic match to find the patient record. Only 84% of login attempts completed.
02
A ceiling on the roadmap
Without verified identity and strong authentication, treatment information, online billing, and document export were not features we would put online. The commerce funnel stopped exactly where the money was.
03
Writes need a verified identity
Insurance updates, address changes, and pre-visit check-in forms are writes, and writes deserve an identity that has been verified, not just matched.
04
A large estate, no big bang
Multiple GraphQL gateways and many microservices — Patient Account, Patient, Scheduling, Document — ran the business daily. Whatever changed had to land without a service-by-service rewrite.
04 — Approach

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.

05 — Architecture

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.

Digital Commerce Platform — system architecturechannels → gateways → services → data
Booking & patient channels
AI Chatscheduling
Online Schedulerself-serve
Call Centeragent console
Local Officesin-person
Patient PortalNext.js 16 · App Router
Mobile Appsnative tokens
▼
Identity platform · Auth0 tenant
signup + verified email/phone · patient-chosen MFA · patient linking in app_metadata · custom claims on every token
▼
GraphQL gateways
GraphQL ABearer JWT
GraphQL BBearer JWT
Content GraphQLcontent
▼
Microservices & data
Patient Accountlookup · linking
Schedulingappointments
Patient · DocumentJWKS-validated
Patient DBsystem of record
06 — What we shipped

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.

07 — Results

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.

first month
100K+ accounts
Real patient accounts, each with an email and phone verified at signup and MFA enrolled — undeliverable contact data can't enter.
from about a minute
Under 20 s sign-in
Median returning sign-in with password and MFA. The old magic link took about a minute, and longer when the email was slow.
unlocked
Roadmap unlocked
Treatment info, online billing, and document export now have the identity foundation they need.
one estate
No rewrite
Existing services accept the new tokens via JWKS + the same identifiers — 8+ services updated, none replaced.

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.

6 teams
Security · Product · Legal
Infra · QA · UX
3 orgs
Enterprise · Web · RCM
engineering
8+
services changed,
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.
— Reflection on the platform build
08 — Reflection

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.

09 — Further reading

The platform, in more depth.

01
Three years of the multi-brand Next.js monorepo: the three architectural eras, the GraphQL gateway, and theming shared across web and Flutter.
02
A Windy City DevFest 2024 talk on running this platform's Next.js apps in production: server rendering, feature toggles, OpenTelemetry outside Vercel, and the prefetch and memory pitfalls.
Back to the index

See all five case studies.

All 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.