Day 2: Reskinning with Google Stitch from a Hotel Room

The Starting Point

Day 1 left me with a working blog — dark mode, cyber lime accent, monospace typography. It looked like a VS Code theme had a baby with Medium. Functional, but generic. The kind of thing you get when you describe a vibe in words and let an AI fill in the blanks.

I wanted something with more intentionality. A real design system, not just a color palette. Typography pairings. Surface hierarchy. Component-level specs. The problem: I'm not a designer, I'm building this from my phone, and I don't have Figma open.

Enter Google Stitch.

Prompting Stitch (and the Brand Guidelines Trick)

My first pass was generic — I asked Stitch to design a site based on a typical CEO thought leadership blog, Medium-style layouts and functionality. The result featured some rather aggressive neon styling that wasn't what I had in mind.

But Stitch can do something more interesting than interpret vague prompts. Instead of manually tweaking colors and fonts, I pointed it at Coder’s brand guidelines and let the AI extract what it needed — color palettes, typographyt choices, overall visual styling. It essentially created an offshoot of my company's brand identity without me specifying a single hex value or font name. The AI understood the brand context and applied it consistently across the entire site design.

That's the real unlock: if you have existing brand assets anywhere on the web, feed them to Stitch instead of describing a vibe in words.

What Google Stitch Actually Gives You

Google Stitch is a design-to-code tool. You describe what you want (or point it at brand guidelines), and it generates full-page HTML mockups with embedded Tailwind CSS — complete with a color system, typography scale, and component patterns. It also outputs a DESIGN.md file that documents the creative direction, naming it with a "Creative North Star" label.

From the brand-informed prompt, it generated a zip file containing:

• 4 page types — home feed, article view, manifesto/about page, connect/contact page
• 3 variants per page — each with slightly different layouts and interaction patterns
• 2 complete design systems — this was the surprise

The zip contained 12 HTML files and 2 DESIGN.md documents, each describing a fully distinct visual identity. Not variations on a theme — two completely different design systems with different color palettes, different font stacks, and different component philosophies.

Two Themes, One Zip File

I didn't expect this. When I extracted the zip and started reading the HTML, the first two variants of each page shared one color system, and the third variant used something entirely different.

Theme A — "The Digital Architect" lived in the cyber_ceo/ directory. Editorial, magazine-like. Neon green primary (#9cff93), purple secondary, cyan tertiary. Inter for headlines, Newsreader (a serif) for body text, Space Grotesk for labels. Glass cards with green glow effects. The whole thing felt like a Bloomberg Terminal redesigned by a fashion magazine.

Theme B — "The Neon Brutalist" lived in vibes_protocol/. Completely different personality. Lavender primary (#dcb8ff), hot pink secondary (#f7acff), coral tertiary (#ffb4a5). Space Grotesk for headlines, Inter for body — the font roles reversed from Theme A. Gradient text, gradient buttons, no glass effects. More austere, more technical.

Both themes shared some DNA — Material Design 3 surface token naming, a strict "No-Line Rule" (no 1px borders for layout, only tonal shifts), Space Grotesk for labels in both cases, identical border-radius configs. But they diverged on everything that matters for visual identity.

I had to pick one. I went with B.

Why The Neon Brutalist

Theme A's green primary was too close to the existing cyber lime accent I was trying to replace. It would have been a lateral move — a nicer version of the same idea. Theme B was a genuine departure. The lavender-pink-coral palette felt warmer and more distinctive. The all-sans-serif font stack (no Newsreader serif) was cleaner for a technical blog. And the gradient text on the hero felt like it had more personality than a single accent color.

The DESIGN.md for Theme B was opinionated in useful ways. "1px solid borders are strictly prohibited for sectioning." "Shadows are never pure black." "Never use pure white text — use on-surface (#e2e2e2)." "If accessibility requirements demand a border, use the Ghost Border: outline-variant at 15% opacity." These aren't vague mood boards — they're implementable constraints.

The Reskin

Applying the design system was systematic work. The blog has a clear architecture — globals.css for tokens, layout.tsx for the shell, then 7 components and 5 page files that compose the public UI. Admin pages and API routes stay untouched.

The mapping was straightforward:

The font change was the most impactful. Adding Space Grotesk for headlines and labels gave the site a geometric, technical feel that Inter alone couldn't deliver. Fira Code replaced JetBrains Mono for code blocks — a subtle change, but the ligatures are nicer.

Every component got the same treatment: replace hardcoded hex values, swap font references, adjust hover/focus states to use the new accent colors. The reading progress bar went from a lime gradient to a lavender-to-pink gradient. Selection highlighting went purple. The hero title got gradient text (from-primary to-secondary).

One build. Zero errors. Pushed to main, Vercel deployed. The whole reskin took about 20 minutes of active direction.

The Light Mode Question

Then I asked: "The Stitch design should have both light and dark theme designs. Can you find the light theme and make it togglable?"

It didn't. Neither DESIGN.md file mentions light mode. Both are explicitly dark-only systems. The vibes_protocol doc literally says "embrace the starkness of a dark environment." Every HTML variant uses <html class="dark">. There is no light palette anywhere in the Stitch output.

This is worth noting as a Stitch limitation — or maybe a reflection of the prompt I gave it. Either way, if you want light mode from Stitch, you'll need to ask for it explicitly or derive it yourself.

Deriving a Light Theme

We derived one. The approach: invert the surface hierarchy and deepen the accents for contrast on white backgrounds.

The dark palette uses pastel accents on dark surfaces — lavender #dcb8ff pops against #121414. But that same lavender fails WCAG AA contrast on white. So every accent needed to be darkened for light mode:

The surfaces got a subtle purple tint — #faf8fc instead of pure #fafafa — so the light theme still feels related to the dark one. Same family, different time of day.

The Token Refactor

Here's what made the light mode actually work: we had to rip out every hardcoded hex color and replace it with semantic Tailwind tokens.

The first commit (the reskin) used hardcoded values everywhere — text-[#e2e2e2], bg-[#1a1c1c], hover:text-[#dcb8ff]. That's fine for a single theme. For two themes, it's a dead end. You can't conditionally override arbitrary hex values in CSS.

The second commit converted everything to token classes: text-on-surface, bg-surface-low, hover:text-primary. These compile to var(--color-on-surface), var(--color-surface-low), etc. — CSS custom properties that Tailwind v4 generates from the @theme block. Then a [data-theme="light"] selector overrides all the variables in one place.

Every component went through this:

text-[#e2e2e2]     → text-on-surface
text-[#cec2d4]     → text-on-surface-variant
text-[#dcb8ff]     → text-primary
bg-[#1a1c1c]       → bg-surface-low
bg-[#282a2a]       → bg-surface-high
border-[#4c4452]   → border-outline-variant

Twelve files changed, zero admin files touched. The token refactor was the real work — the light palette definition was just a block of CSS variable overrides.

Preventing Flash

One thing that's easy to get wrong with theme toggles: the flash of wrong theme on page load. If you default to dark in HTML and the user has light saved in localStorage, they see a dark frame before React hydrates and flips the theme. It's jarring.

The fix is an inline <script> in <head> that runs before the browser paints:

(function(){
  var t = localStorage.getItem("theme");
  if (!t) t = window.matchMedia(
    "(prefers-color-scheme:light)"
  ).matches ? "light" : "dark";
  document.documentElement.setAttribute("data-theme", t);
})()

No React, no hydration — just a synchronous DOM attribute set before the first frame. The theme toggle component then picks up the same state on mount.

The Mobile Workflow

The entire process — from design to deployed site — happened from my phone in a hotel room. The pipeline looks like this:

1. Design in Google Stitch — create and refine the site design in the browser
2. Export to mobile — download the zip file to iPhone Files
3. Upload to GitHub — use GitHub's web interface to push the zip to the repo
4. Agent processing — Coder agents detect the new file, extract it, and apply the design

In practice: Stitch exports a zip, which downloads straight to the iPhone Files app. From there I opened GitHub's web UI in Safari, navigated to the repo, and uploaded the zip to a branch. Once it landed in the repo, Coder Agents had access to the file — they extracted the zip, read the HTML and DESIGN.md files inside, and applied the design system to the codebase.

It works, but the iOS Files → GitHub upload step is friction. You're bouncing between apps, navigating folder structures on a phone keyboard. The ideal would be direct integration between design tools and deployment platforms, cutting out the file management in between. These are the kinds of workflow seams worth smoothing out.

What I Learned

Stitch gives you more than you expect. I asked for a redesign and got two complete design systems with documented creative direction. The DESIGN.md files alone are worth the exercise — they articulate design decisions in a way that's directly implementable. "No-Line Rule," "Ghost Border Fallback," "7-tier surface hierarchy." These are the kinds of constraints that make a design system cohesive.

Stitch doesn't give you everything. No light mode. No responsive breakpoint specs. No animation timing guidance. No accessibility annotations beyond a brief mention of WCAG AA. The HTML it generates is static Tailwind — good for extracting a design system, not for dropping into a production app.

Two themes in one export is both a feature and a friction point. It's great to have options. But if you're feeding this to an AI coding agent, you need to identify which variant maps to which system and make a choice. The variants aren't labeled in the filename — you have to read the CSS to figure out which design system each one belongs to.

Token-first is the only way to do themes. If I'd started with semantic tokens on Day 1, the light mode would have been a 20-line CSS change instead of a 12-file refactor. Lesson learned: even if you're building dark-only, use design tokens. Future you will thank present you.

The design-to-code pipeline is real. Stitch → Claude → deployed site, in one session. No Figma. No design handoff. No "pixel-perfect" arguments. A generated design system, interpreted by an AI coding agent, applied to a production codebase. The fidelity isn't perfect — it's an interpretation, not a screenshot recreation. But it's good enough to ship, and you can refine from there.

By the Numbers

• 2 design systems extracted from one Stitch export
• 12 HTML mockups analyzed (4 page types × 3 variants)
• 13 files changed across 2 commits
• 1 new component (ThemeToggle)
• ~50 color tokens mapped from hardcoded hex to semantic names
• 0 admin files touched
• 2 builds, both zero errors
• 1 evening session, still from my phone