Build for change, not just launch.
Bring the content editor, design system, and development foundation together so each client site can grow without starting over.
Start with the work the site needs to do.
Shape the content
Use heroes, editorial sections, collections, and calls to action according to the content. The block library is a toolkit, not a mandatory page template.
Browse the blocksCarry the brand through
Register client colors, type, surfaces, and actions once in the token system. Editors choose meaningful values; the frontend uses the same design language.
See the design systemExtend deliberately
Keep the parent theme updateable. Add client-owned patterns and named presentations, then enable optional modules only when the project calls for them.
Explore extensions
Brand decisions belong in the system.
The token registry gives the editor and frontend the same palette, widths, type, and action vocabulary. A child theme can change the defaults without forking the blocks.
What editors change. What developers own.
For the people publishing
Change copy, imagery, and relevant layout choices in Gutenberg. Named block variations make site-specific recipes visible instead of hiding them in page CSS.
For the people building
Own the client brand in the child theme. Use extension hooks for structured data and integrations, while keeping fixes to the shared parent and blocks updateable.
Use the right content model.
Use a real content model for people, events, and collections. Add forms, consent, help, and performance tools as needed. Not every module has to ship on every site.