Problem: Construction delays pushed back projector installation, which cascaded into delayed content finalization and difficulty scheduling team trips for on-site calibration.

Fix: Served as mediator between fabrication, integrators, audio, and video teams — tracking digital infrastructure status on-site to coordinate when to fly people in. Built a shared schedule and checklist with fabrication and integrators to flag where we were off track and decide when to modify exhibits to hit the deadline.

What I'd do differently: I'd build the shared tracking system from day one instead of waiting until delays surfaced. Now I start every multi-vendor project with a shared infrastructure status board before anyone is on-site.

Problem: The motion tracking room was designed for one guest controlling a Jon Snow silhouette, but multiple people would enter and try it together, confusing the sensor.

Fix: Added a docent to guide guests while we updated the tracking code to lock onto the centermost and front person. Also added a lit floor mark to clarify the interaction point — reducing sensor confusion and keeping the experience smooth for groups.

What I'd do differently: I'd test every interactive room with groups, not just individuals. Single-user testing missed the most common real-world behavior. Now I always run multi-person stress tests for any body-tracking installation.

Problem: The GitHunt scavenger hunt experienced lag due to the venue's local network and hardware not being able to support the system.

Fix: Ran it on day one while troubleshooting, then made the call to cut it for day two — recognizing the sunk cost and prioritizing attendee experience over keeping a struggling feature live.

What I'd do differently: I'd require a full network stress test at the actual venue before committing to any feature that depends on local infrastructure. Conference networks are unpredictable — now I always have a local-only fallback for network-dependent features.

Problem: The system was initially built for our team to manage, but we didn't know who would maintain it long-term — leaving it in a state only we could operate.

Fix: Built a full scheduling and playlist CMS so building staff could update content, create custom playlists, and set time-of-day schedules independently. The system now runs remotely during working hours with zero downtime for updates.

What I'd do differently: I'd identify the long-term operator in the first week of the project, not midway through. Now I always ask "who runs this after we leave?" before writing a single line of architecture.

Problem: Player names and positions could change quickly between games, risking misrepresented player info on the stage visuals during the live broadcast.

Fix: Built a custom GUI for swapping assets live without downtime. This also cut prep time to 30 minutes per match for verifying all player assets were correct before going live.

What I'd do differently: I'd build the asset-swap GUI into the original spec rather than as a reactive fix. For any live tournament format, player data volatility should be a first-class design constraint from the start.

Problem: Course timing varied nightly, requiring a strict schedule without rushing guests or letting the experience feel stale between courses.

Fix: Layered the sensory cues — food arrived with audio and scent first, then video followed to keep lighting on the dish before the walls took focus. Between courses, generative visuals ran as an endless ambient loop so the room never went dark while servers reset for the next dish.

What I'd do differently: I'd run a full dress rehearsal with the actual kitchen team earlier in the process. We rehearsed with test timing, but real kitchen variability was wider than simulated. Now I always insist on at least one real-conditions rehearsal with the actual operators.