Why composable architecture wins for multi-site teams

Wunderman Thompson, a global digital agency with teams across Europe, manages digital experiences for multiple countries, languages, and portfolio brands — each with its own visual identity. Their approach combines Atomic Design principles, a headless CMS, a monorepo, and Vercel's serverless platform to keep everything in one codebase.

The shift from PHP servers and WordPress monoliths to this composable setup delivered dramatic gains: development time dropped by a factor of 10, and costs by a factor of 25. The core idea is simple — one source of truth for code and data, reused across every client site.

Start with a component-based framework

The foundation of an efficient workflow is the framework you build on. Next.js and SvelteKit both support the complex, layered component hierarchies that a multi-site design system requires. Key advantages include:

  • Full-stack capabilities: Built-in routing, server-side rendering, APIs, and middleware mean you serve frontend and backend code from one application.
  • Component architecture: Reusability and modularity are baked into the model, keeping code maintainable as the system grows.
  • Performance optimization: Dynamic imports and code splitting let you defer scripts to the component level, serving only what the client actually uses.
  • Modern rendering options: Support for Incremental Static Regeneration (ISR) pre-renders dynamic data without requiring a redeploy when content changes.
  • Framework-defined infrastructure: With Vercel, infrastructure is provisioned automatically based on your project's framework, simplifying deployment and boosting team velocity.

Both frameworks also allow incremental adoption and ease of migration — important when you're consolidating legacy systems into a single, scalable codebase.

Organize components with Atomic Design

Wunderman Thompson uses Brad Frost's Atomic Design methodology to structure its shared component library. It defines five levels — atoms, molecules, organisms, templates, and pages — that let teams build complex interfaces from small, reusable pieces. This is one proven way to organize a codebase; it's particularly well-suited to managing many sites from a single set of components.

Start with atoms

Atoms are the smallest reusable components, such as a Button.js, InputField.js, or Label.js. They can also be layout primitives like flexbox or grid, or CSS variables defining brand tokens like --var-background and --var-accent-1. The goal is to quickly build a shared visual vocabulary so designers and developers can work in parallel rather than in a sequential waterfall.

Combine atoms into molecules

Molecules group atoms into versatile units like search bars, cards, tooltips, or alert messages. Apply the single-responsibility principle — each molecule should do one thing well. For example, a SearchBar.js molecule might combine input field, label, and button atoms.

Build organisms

Organisms are larger sections — headers, footers, menus, product displays. These start to reflect the specific needs of your application. A header organism, for instance, might import a search bar molecule along with menu and site title molecules.

Templates and pages

Templates arrange organisms into a layout that accepts dynamic data instead of hard-coded content. Pages are produced when you populate those templates with client content via the headless CMS. Well-built templates can be customized down to the component level, so each client brand looks unique while sharing the same underlying code.

A headless CMS as the single source of truth for data

Before adopting a headless CMS, Wunderman Thompson ran each client on its own server infrastructure, with a custom CMS and a bespoke site — duplicating effort for every new engagement. Now the agency centralizes all customer data in DatoCMS, grouping similar clients while keeping data private.

Onboarding a new client is reduced to a matter of days. Common data points are templated — for instance, when adding Sogrape and its wine sub-brands — and new sites are assembled from pre-existing organisms configured with the client's unique branding and content. Adjustments become a matter of tweaking parameters or reordering components in the CMS rather than writing new code.

Keep all code in a monorepo

The CMS handles data; the code lives in a monorepo. Wunderman Thompson stores all Next.js components in a single Turborepo-managed repository. Each client site is deployed to be visually distinct, but runs on the identical component set. An environment variable in each deployment maps to a unique client ID defined entirely in the headless CMS.

This arrangement lets the team focus on building high-quality components once. New client requirements are built from existing atoms, ensuring consistency and easy integration. Because every developer works against the same codebase, components stay aligned and teams can navigate the monorepo without friction.

Turborepo brings intelligent caching that cuts build times significantly. With Remote Caching, once a team member runs a build, every developer and the CI system can access that cache — an advantage that compounds as the team scales. That speed is critical when building for many sites places constant load on your CI pipeline and iteration speed is bound to client demand.

From monolith to modular: managing multi-site in one repo

Wunderman Thompson’s shift to a composable architecture relies on a unified Turborepo monorepo that holds every client site. A shared design system and UI package live at the core, with individual Next.js sites consuming from it. This means changes to shared elements propagate across all properties through standard dependency updates — no more duplicating code or fighting version drift across separate codebases.

On the content side, the team uses a single DatoCMS project with a site field as a distinguishing taxonomy. That keeps editorial workflows centralized while still allowing total visual and structural independence per site through webapp and template overrides. The main challenge was refactoring an inherited codebase from a traditional server setup into this modular structure, a process that demanded careful, incremental migration work.

Handing off the heavy lifting

Vercel’s approach is built on Framework-defined Infrastructure (FDI): it natively recognizes and integrates with Next.js, DatoCMS, and Turborepo, removing the need for teams to custom-build deployment pipelines. DatoCMS users can kick off Vercel deployments directly from the CMS dashboard, for instance, and Next.js analytics data flows straight into the Vercel Analytics dashboard without extra configuration.

Two operational advantages stand out for multi-site teams:

  • Preview deployments. Every commit on every Git branch produces a live preview that runs on the real edge network, so clients see final performance characteristics before merge. Vercel’s Figma-style commenting tool lets stakeholders leave feedback directly on the preview, cutting out screenshot chains and lengthy email threads during iteration.
  • Serverless scaling. Previously, Wunderman Thompson ran a dedicated server per client, paying to scale capacity up as traffic grew and eating idle costs when it didn’t. Serverless removes that capacity planning entirely — infrastructure expands and contracts automatically, and only used compute is billed.

For international properties, the global edge network supports localization out of the box. Wunderman Thompson stores localized site versions inside the CMS; adding a new language is as simple as adjusting an environment variable in the Vercel deployment.

What a shared frontend buys you

The results Wunderman Thompson reports are dramatic: roughly 10x developer productivity and a 25x cost reduction relative to the previous monolithic WordPress setup. The workflows enabled by the composable stack also change client relationships. Live previews for a new site can be delivered within a week, complete with commenting and edge network performance.

Teams that standardize on a unified monorepo, a headless CMS, and framework-native infrastructure get fewer moving parts to babysit. The design system updates once and flows to every site; deployments trigger from the tools editors already use; and the infra layer never becomes a bottleneck during traffic spikes. That combination keeps the development focus on shipping product features rather than on duct-taping together disjoint systems.