Photon: React in Windows
Measuring what a new hosting architecture actually costs at launch.
There was no prior art for hosting a React-delivered page inside Windows Settings. I was the first use case of hosting one as the app's L1 landing page, which meant the interesting question wasn't whether it could be done. It was what it cost, and nobody had a number to argue from.
I chose to establish a floor before benchmarking anything real. First, launch traces for a "Hello, world!" React page and a Hello World XAML page; then the harder launches, the existing XAML homepage and the React-delivered Accounts page. The rejected alternative was the obvious one, timing the XAML homepage against a React homepage head-to-head. That produces a single number that silently mixes hosting overhead with page content, and nobody can make a decision from it. Baselines turned a set of measurements into a cost model.
The other half of the deliverable was the setbacks. The path was full of unprecedented failures, so I wrote down how to reproduce it: environment setup, patching, debugging, common pitfalls. That documentation went into the Photon team's approved wiki, along with additions I contributed on getting a VM into a workable state for Settings development. It surfaced gaps between what Photon assumed their consumers knew and what we actually knew, and they used it to improve the service. The findings became the foundation for the Settings homepage architecture, and I later prototyped a ReactNative-based homepage on the same ground.
In platform work, a well-characterized cost model is often worth more than shipped code. The deliverable was certainty.