A site running on a page builder for 5 years, degraded performance, maintenance that had become increasingly painful. The client didn’t want to tear everything down — they wanted the same design, on healthier foundations. This is exactly the use case where modularizing an FSE design system makes all the difference.
Migrating Without Rebuilding
The temptation, in situations like this, is to start from scratch. New design, new architecture, new content. It feels reassuring on paper — but it’s often the wrong answer.
When the design works and the content is solid, the problem isn’t what’s visible. It’s what’s happening underneath: a page builder stacking modules, loading dozens of unnecessary resources, making every change risky.
Migrating to a native FSE (Full Site Editing) theme solves this without erasing everything. The design stays. The foundation changes.
The Design System as Backbone
A native FSE theme is built on a design system defined in theme.json. This file centralizes the theme’s global variables: colors, typography, spacing, button styles.
But a design system can’t be managed as a single block. On a complex project, the slightest cascading change can spiral out of control. The key is fragmentation: each domain is handled separately, with its own rules and its own procedures.
In practice, that means:
- Colors in their own domain — palette defined once, reused everywhere
- Spacing in theirs — values dynamically calculated with
calc(), consistent across screen sizes - Typography separate — fluid sizes that adapt to the viewport without fixed breakpoints
- Button styles apart — isolated variants, modifiable without risk
Each domain becomes a documented procedure. A clear rule, reproducible from one project to the next.
Claude Code as a Domain Partner
This is where Claude Code comes in. The idea isn’t to use a generalist agent that generates code in bulk. It’s to associate each technical discipline with a dedicated skill — a precise instruction that Claude Code knows and can repeat.
In my practice, skills are organized by technology and responsibility:
- CSS — indentation standards, FSE variables, media queries
- JavaScript — ESLint conventions, JSDoc, Gutenberg patterns
- PHP — PSR-4 namespaces, security, phpDoc, performance
- FSE — site editor gotchas, Block Bindings, template overrides
- Patterns — file format, cache behavior, global styles
- Standard — orchestrator that detects modified files and calls the right skills
- Security — end-of-session audit for PHP and JavaScript
Each skill operates within its own scope without overlapping others. Claude Code can modify CSS without risking breaking PHP logic. Work on a pattern without touching JavaScript conventions. Precision comes from the structure — not from the tool itself.
For more complex tasks — generating a complete block from a description — an agent draws on the existing block library and applies the project’s standards. The design system becomes its reference.
From Variables to Loading: Performance by Design
The design system variables aren’t just for maintaining visual consistency. They become the foundation for everything else — components, custom stylesheets, JavaScript or PHP blocks when the editor falls short.
And loading follows the same fragmentation logic. Each stylesheet only loads if the corresponding block is present on the page. Same for scripts associated with custom blocks. No unnecessary resources — something that was impossible with a page builder loading everything at all times.
Why an All-in-One Generator Doesn’t Hold Up
The temptation is strong to want a single tool that handles everything: design system, blocks, styles, content. In practice, on a complex site, this kind of approach is too tightly coupled to be maintainable.
When everything depends on everything else, even minor changes become risky. And when Claude Code works inside an overly coupled system, it loses track — domains overlap, variables conflict.
Modularization solves this at the root. Each part of the system is independent, auditable, replaceable. The whole holds over time — and evolves cleanly.
Conclusion
Migrating a page builder site to FSE isn’t about rebuilding a site. It’s about giving it an architecture that can evolve without collapsing.
Modularizing the design system is what makes Claude Code genuinely useful on complex projects. Without it, the tool amplifies the chaos instead of reducing it. With it, every intervention is precise, documented, and reproducible.
If you’re working on this kind of migration or want to structure your FSE workflow with Claude Code, I’m happy to talk: contact