Phoenix

A static site that had run out of room.

For nine years xinjiangshao.com was a static site: a Jekyll blog from 2016, then Hugo from 2017. Markdown files, hand-tuned templates, and a build step that spat out flat HTML. It was fast, cheap, and easy to reason about — exactly what a static generator promises.

But every idea I had bumped into the same wall. Anything dynamic — a chat that knew my writing, audio narration of a post, live data, a small app I wanted to try — was either impossible or a hack bolted onto a system that was never meant to do it. The blog was frozen at build time, and I wanted a place that could respond.

From a Jekyll blog to a platform.

The Internet Archive has saved 37 distinct copies of the homepage since February 2016. Read in order, they show the site moving from who I am to what I’ve built, and each rewrite changing what the <title> tag said about my job.

1. 

   2016

   A Jekyll blog

   Kasper theme, a full-bleed photo of my desk, and five posts below the fold. Four of them are still on the site.

   Xinjiang's Stuff - Web Developer, App Developer, and Much More

2. 

   2017

   The contact card

   Rebuilt on Hugo as one dark screen: a photo, one sentence about my job at Peapod, an email address, a PGP key and three links.

   Xinjiang's Stuff - Xinjiang Shao is a Full Stack Developer in Chicago @soleoshao

3. 

   2020

   A personality

   Same frame, more voice: Senior Software Engineer at Peapod Digital Labs, and the first mention of wanting to be a chef.

   Xinjiang Shao - Xinjiang Shao is a Senior Software Enigneer living in Chicago, IL

4. 

   2022

   The blog takes over

   An off-the-shelf theme, PaperMod. The homepage shrank to a name and a sentence, and the menu did the work: posts, tags, search, then photography and a newsletter.

   Xinjiang Shao

5. 

   2023–25

   Bilingual, with a tagline

   A Zh link, a Talk page, and the chef as the headline. The title tag went from Software Engineer to Lead Software Engineer.

   Xinjiang Shao - Lead Software Engineer

6. 

   Oct 2025

   Phoenix launches

   The Next.js homepage became a portfolio, with demos, testimonials, a floating chat and the latest post. Its content lived only in the JavaScript payload, so the archive replays it as a blank page. This screenshot comes from running that commit locally.

   Xinjiang Shao - Principal Software Engineer

7. 

   2026

   Proof, names, positions

   January added numbers, April retired the chef tagline, July named the brands, and October led with scope and four positions I’ll defend.

   Xinjiang Shao | Principal Software Engineer

8. 

   Now

   The editorial site

   One paper-and-ink design across every page, case studies and product pages, rendered on the server.

   Xinjiang Shao — Principal Engineer, Healthcare Platforms

Rebuild it live — without losing what already worked.

Project Phoenix was a full rebuild, done solo. The static site was legitimately good, so the migration had a high bar: keep everything that made it fast and durable, and add everything a dynamic, AI-native platform makes possible. Four constraints shaped it:

An AI-native Next.js platform.

The new site is Next.js 16 on the App Router with React Server Components as the default — content renders on the server and streams to the client, so most pages stay as lean as the old static ones. Interactivity is added deliberately, only where it earns its weight.

The AI layer is the part that couldn't exist before. Claude, Gemini, and OpenAI each do the job they're best at: Claude runs the chat through the Vercel AI SDK, with an MCP client that lets it reach live tools at request time; Gemini writes post summaries; OpenAI narrates posts and transcribes the audio into subtitles. Firebase handles auth, data, and hosting, so the whole thing runs as one deployable app.

How the pieces fit.

Client on top, Next.js in the middle rendering and routing, an AI orchestration layer fanning out to models and tools, and Firebase holding content and state.

The capabilities the old site couldn't have.

The redesign, done with AI as the co-designer.

The rebuild wasn't just an engineering migration — it was a visual reset. I used AI tools throughout to explore layouts, generate an atomic component system, tune tokens, and pair-program the implementation. What would have been a months-long solo rebuild happened in a fraction of the time, and the design got more exploration, not less.

The site is now a place to try things.

The real payoff of going dynamic is optionality. Ideas that were impossible on a static generator are now a weekend project — the platform is the sandbox, and each new experiment ships to the same live site.

The platform kept moving after the migration.

The rebuild started in August 2025. Everything below shipped on the same platform afterwards, most of it as small pull requests: more than 80 have been merged since this case study first went up in July 2026.

Not everything stayed. The JSON linter, Markdown preview and translator were retired in November 2026. Unpublished drafts moved out of the public folder, so nothing is reachable before it's ready.

A performance pass, November 2026. A PageSpeed run that morning scored the homepage 80 on desktop, held back by 460 ms of blocking time. A CPU profile mapped back to source found most of it in a syntax highlighter registering about 300 languages on every page, pulled in through a shared component index for a component nothing rendered. Three pull requests later: that dead code is gone, English pages no longer load a Chinese web font's CSS, Sentry Replay loads after the page goes idle, and Firebase Auth loads only on the pages that sign people in.

Build the platform, not the page.

The temptation with a personal site is to keep polishing the page in front of you. Phoenix worked because I stopped optimizing the artifact and started building the substrate — a platform where the next idea already has a home, a data layer, and an AI layer waiting for it.

The other lesson was about pace. Doing this solo would once have meant scoping down hard. With AI as a co-designer and pair programmer, the constraint flipped: the bottleneck became deciding what to build, not finding time to build it. That's the whole reason the site exists now — to keep answering that question.

A year on, the third lesson is that a platform needs pruning as much as building. What I take away is part of what I ship.