the prototype that became the launch app

The GR brand's US retail launch needed a dealership moment: a real-time Unreal configurator of the GR GT on an LED video wall, controlled from a tablet, in showrooms across the country. The budget arrived before a concept did.

Waiting for the process to produce a concept would have spent the schedule. So I built the proof of concept myself, outside the production process: the Unreal changes, a local web server, the tablet control surface and the rules updates, on real hardware.

The prototype did what proofs of concept are supposed to do, and then something they usually don't. When engineering planned the launch build, it chose to reuse the prototype almost entirely instead of rebuilding it, and parked a full enterprise rebuild as a post-launch option. The thing I built to win the argument became the thing that ships.

That changed my lane. I now implement the in-dealer app itself: Unreal changes, packaging the shipping build, the local web server, the control surface, rules updates and hardening, all through AI-assisted development. Design delivers comps. The platform team owns the launcher, installer and updater, the kiosk runtime and security, telemetry, and a shared, versioned rules snapshot the dealer PC pulls with a manifest, a hash and a rollback path.

A wall in a showroom is a digital platform with a power cable, and the expensive failures are ownership failures. Early on I wrote the model down for the hardware side: cleanly separate build ownership from deployment execution. The agency ships a validated, versioned golden build. The screen vendor images and provisions the hardware, rolls out, rolls back, and runs L1 and L2 support. A defect report starts with a build version, and the version tells everyone whose problem it is.

Writing the line down before anything shipped is the point. Ownership boundaries agreed in calm weather are the ones that hold when a wall goes dark on a Saturday.

The in-dealer app and the web configurator are two stages of one system. Both take their rules from the same validated source, and both renderers follow the same principle: the rules engine decides what a valid car is; the UE5 wall, like the cloud stream, only draws the state it's handed. The delivery plan was re-cut along those lines, with lane labels per team and resumable, receipt-keeping scripts applying the plan to the tracker so a half-finished restructure could never leave the backlog in an unknown state.

Pre-launch, so the outcome so far is structural: a prototype that survived contact with engineering review and became the launch app, a product lead holding the implementation lane under the same review as everyone else, and an ownership line with the hardware partner that was written before it was needed.

The lesson I'd take to any experiential program: a working prototype on real hardware ends the concept-and-estimate loop faster than any deck, and if it's built with the shipping architecture in mind, it doesn't have to be thrown away. The full story, with dates and what the rollout taught, comes after launch.