Meta Ray Ban Demo Scheduler
Visit LiveRole
Full-stack engineer (IC)
Stack
React (Flow), GraphQL, Relay, PHP
Status
Live
Description
Meta's demo scheduler, where shoppers book an in-person try-on of its Ray-Ban smart glasses at a participating retailer. It runs as a white-label system across multiple retail partners, covering booking, rescheduling, cancellation, waitlists, and walk-ins on desktop and mobile.

I joined the Demo Scheduler as a full-stack engineer to take on a set of work across the booking and testing layers: rebuilding the in-store registration flow, moving retailer configuration out of hardcoded logic, changing how booking data was passed, and standing up the project's first E2E tests.
What I worked on
- Rebuilt the in-store walk-in registration flow with a new flow and UI: a multi-page React experience (intro, form with phone formatting, confirmation), responsive, behind a feature flag, later extended to support multiple retailers with server-side validation.
- Moved white-label retailer logic from hardcoded conditionals to centralized remote config across 8+ PHP controllers and the scheduling API layer, so onboarding a new partner no longer took a code change.
- Moved booking parameters (slot, store, date/time, retailer) from URL query strings to component props, so users could no longer edit booking data through the URL. This applied across every white-label partner.
- Wrote the project's first E2E test, then built the suite to 30+ flows covering booking, modify, cancel, waitlist, walk-in, and store-availability sign-up across desktop and mobile, with happy-path coverage on each.
- Authored PHP mock functions for 7 external scheduling API endpoints (schedules, availability, appointment create and update, waitlist, store info, walk-in), so the tests ran against consistent data instead of live staging.
- Replaced inline React rendering in the booking flow with a route-based controller stack (PHP controller, route, React entrypoint), so booking supported real browser history and back/forward navigation.
Building the tests
To keep the tests from relying on flaky staging data, I added a mock layer in front of the 7 scheduling endpoints and had it return consistent timestamps across calls. While building it, I hit a timezone bug: the tests failed only between 5 pm and midnight Pacific. The server-side mocks were generating "tomorrow" based on local server time, while the JS tests formatted dates differently, so after 5pm PST, the two sides disagreed on which day it was. I aligned the mocks to use request time plus an offset and moved the JS tests to UTC. That cleared it.
Result
- The project went from no automated E2E coverage to 30+ flows, run against a 7-endpoint mock layer instead of live staging.
- Retailer onboarding moved from per-partner code changes to centralized config.
- Booking data could no longer be edited through the URL, across every white-label partner.
