john mark lowry
§ platforms · 2024–present

GR GT digital ecosystem

Gazoo Racing's US launch configurator: the real lexus.com Build lineage with a live cloud pixel stream of the Unreal car as the render stage — designed by its product lead, then built by its product lead too.

an unreleased client program. this page stays at the pattern level on purpose: no launch dates, partners, vendor names, metrics or internal artifacts until after launch, and only then with clearance.

01 · the moment

Gazoo Racing's US launch needed a configurator worthy of the car: the lexus.com Build lineage (the configurator line that won JD Power best in class) as the logic, and a live, cloud pixel-streamed Unreal model of the car as the picture. The release is phased, from a first launch with a reduced rule set to full all-valid builds later, and every phase has to ship something real while laying rail for the next.

My role on this program started where it usually does, as the cross-domain architect connecting UI, backend, real-time 3D and partner teams. It didn't stay there. By the fall of 2026 I had taken an implementation lane: I write the launch app, and the engineering teams own delivery, integration, infrastructure and QA around it.

02 · the reframe

The default plan was to build the launch experience inside the CMS monolith that runs the rest of the client's web estate. That would have put a launch-critical app behind the monolith's release train, its authoring model and its regression surface. The reframe: ship it as a standalone static app on the client CDN, and consume the production Build component libraries through a pinned library ref. Developers keep upgrading the reusable pieces where they live; the launch app pulls them in deliberately. The CMS comes off the critical path without forking the configurator.

The second call was a principle, agreed with the platform architects before a line of the stream integration was written: the rules engine validates in the UI; renderers never validate. The 2D stage, the cloud stream and the in-dealer UE5 build only draw a state they're handed. One engine decides what a valid car is.

The rules engine validates every selection in the configurator UI, which sends only valid state over a WebSocket contract to three renderers: a 2D image stage, a cloud pixel stream and an in-dealer UE5 wall. Renderer-side validation is the rejected path.
one engine decides, every stage draws — renderer-side validation is the road not taken
03 · the build

Overlay, don't fork. The working demo sits on top of the production Build source without modifying it: a GR theme, GR navigation and footer syndicated live from the brand site, trim select, a text-first conflict modal, and a summary that saves the build as an image and a branded PDF, with saved-build analytics.

A state contract, written down. The web UI and the Unreal stream talk over a WebSocket contract I wrote: the UI sends validated state, the stream reports back, and a small pill tells the shopper whether the car is syncing or synced. Keep-alive, a reset-to-base-car on connect, doors open and closed, and auto-rotate all ride the same contract.

A waiting room, because streams are finite. Cloud pixel streaming is a pool of GPUs, not a CDN. The stream waiting room handles that honestly: in-line screens instead of a blank canvas, retry, a quota check before connecting, and fair-use limits so one tab can't hold a seat all day.

Driving Unreal from another machine. The Unreal project lives on a Windows PC; my development happens on a Mac. A structured handoff repo of context documents lets Claude Code work against the Unreal side with the same discipline as the web side: the contract, the build steps and the live checks, written down once. Packaged stream builds go through scripted live checks before anyone else sees them.

04 · the operating model

A product lead writing launch code is an unusual arrangement, so I set the terms out loud with the engineers. This isn't a case for AI replacing developers. My pull requests get reviewed like anyone else's, engineering owns the integration and the infrastructure, and the tickets I hold are the same shape as theirs. The AI-assisted lane is a capacity decision, not a bypass.

Around the code sits the planning: a launch epic rewritten phase by phase, a stability epic filed against existing library defects before they could become launch defects, and a scenario model for how my time splits between leading the product function and holding an implementation lane, with the fallback written in (an Unreal engineer or a second platform engineer picking up my tickets).

05 · the outcome

Pre-launch, so the honest outcome is the shape of the thing: a launch app that doesn't depend on the monolith's release train, one validation engine shared by every renderer, and a stream integration with a written contract instead of tribal knowledge. I ran the configurator demo in person at Monterey Car Week 2026, in front of the public.

The full case study, with dates, numbers and what launch actually taught, comes after launch. Until then this page says what was decided and why, and nothing that belongs to the client.

Validate in one place and let every renderer just draw. Once the rules engine owns correctness in the UI, a 2D image, a cloud stream and a dealership wall become interchangeable stages instead of three competing sources of truth.

the insight
ran onstandalone static app (S3 behind the client CDN) · shared Build component libraries via a pinned ref · rules engine in the UI · WebSocket state contract · cloud pixel streaming of an Unreal Engine project · AI-assisted development (Claude Code), engineering-reviewed PRs

← all work