Headless Commerce
at B2B Scale

Software Engineer
Component API Lead
Mentor
React
TypeScript
Apollo
GraphQL
Redux
Ramda
Scala
PostgreSQL
Kubernetes
Terraform
When Commerce Is Too Slow For SupportReal-time B2B tooling on a polyglot platform
Under Armour's B2B arm runs on a $1B+ e-commerce platform — Scala services, Kubernetes clusters, Terraform everything. When support teams needed to manage orders, process returns, and handle escalations in real time, the legacy tooling couldn't keep up. Agents were waiting on pages the business couldn't wait for.
I joined the team that fixed that: a headless, Apollo/GraphQL-powered portal that let agents do their jobs in seconds instead of minutes, and a component architecture that outlived my tenure.

The Backbone
Real-Time Data On A Commerce Graph
The commerce graph had everything — orders, inventory, customers, returns, shipments — but support tools were stitched together against legacy REST endpoints that assumed a shopper, not an agent. Latency was fine for a product page and brutal for a ticket queue.
We stood up a headless Apollo/GraphQL layer that sat in front of the commerce services and gave agents what they actually needed: a single query that pulled an order with its line items, shipment status, return history, and customer record in one round trip. The front end subscribed to live updates over Apollo, so when a shipment status changed mid-call, the agent's screen changed too.
- Apollo + GraphQL as the read-path for all B2B tooling
- Real-time data synchronization handling tens of thousands of concurrent requests
- 99.9% uptime on the B2B support surface
- Redux for local UI state that shouldn't round-trip the server
The polyglot stack underneath — Scala services, PostgreSQL, Kubernetes, Terraform — didn't need to change. The GraphQL layer was the translation.
The Portal
What Agents Actually Used

The portal itself was deliberately boring. Support teams don't want cleverness; they want the right data in the right place, and they want it now. We sat with service managers, mapped the three or four workflows that ate most of their day, and rebuilt those as single-screen flows.
- Order management — look up, edit, re-route, split
- Returns processing — one queue, one set of actions, keyboard-first
- Escalations — routing with SLA visibility and a clear handoff trail
The win we could measure was ticket resolution time: 35% faster, driven by fewer tab switches and fewer round trips. The win we couldn't measure was morale. Agents who'd been apologizing to customers for software stopped apologizing.
Standards That Outlived Me
Component APIs And The People Using Them

I was at UA for eleven months. The goal was never to ship my components — it was to ship the patterns the next engineer would copy. Two things carried the most weight:
- Component API standards — prop shapes, event names, accessibility defaults, documented in one place and enforced with comprehensive prop validation
- TypeScript-first patterns — junior engineers pairing on real tickets, not on toy examples, with a specific focus on making 'strict mode' feel like a productivity gain rather than a tax
When I left, feature rollouts were faster because the next person didn't have to relitigate how a form behaves or what a modal header looks like. That's the part of the job that's invisible until you miss it.
Takeaways
What Transferred
Two lessons from UA that I've carried into every role since.
- Real-time isn't a feature, it's a property of the data layer. If the backbone pushes updates, every surface you build on top feels alive for free.
- A component library is social infrastructure. The APIs matter because they determine what future engineers feel safe shipping. Standards are faster than style guides.


