Most "brand architecture" articles are written by strategy consultants who never shipped a Shopify theme. Most "design system" articles are written by engineers who never sat through a brand review. The version you need, if you run a DTC operation, is the one that comes from someone who has done both. I've built nine brands from positioning through production code, including a master-brand rationalization for a multi-brand client (see the brand architecture case). This hub is the map I wish someone had handed me the first time.
The four layers
Brand architecture for a DTC business is four stacked layers, not one. If any of them are missing or drift apart, the surface you ship (the PDP, the email, the ad) reveals the gap. Customers do not diagnose it as "inconsistent tokens," but they do feel it, and they churn.
The layers, top down: strategy (what are we called, what do we stand for, how do product lines relate to the master brand), tokens (the atomic design decisions: color, type, spacing, motion), components (the reusable chunks: PDP hero, cart drawer, email header), and surfaces (where the components render: Shopify, PDFs, ad creative, email).
Strategy without tokens produces a fifty-page brand guide that nobody can implement. Tokens without strategy produce a pretty system that makes every product line look identical and kills line extensions. Components without tokens produce drift. Surfaces without components produce the thing I see on most mid-market DTC sites: three different header styles across the PDP, the blog, and the newsletter footer.
Layer 1: strategy
Strategy answers three questions before you pick a font. What is the master brand called, what are the product lines called under it, and how do those names relate. That is brand architecture proper, and it is the decision that most shops try to skip because it feels abstract.
Two patterns dominate in DTC. A branded house is one master brand with named offerings underneath (Apple with iPhone, iPad, MacBook). A house of brands is a portfolio of independent brands under a holding company, often invisible to customers (Procter & Gamble with Tide, Pampers, Gillette). Most DTC operators default to branded house because the economics of customer acquisition favor concentrating trust in one master brand. The exception is when two product lines serve genuinely different audiences that cannot cross-sell. I cover the decision in house of brands vs branded house for DTC.
The naming layer is where most strategy work happens. A naming ladder that holds for forty products or more is the artifact to build once and reuse forever. Get this wrong and you rebuild it every time a line launches.
Layer 2: tokens
Tokens are the atomic units a brand system compiles into everything else. Color, type scale, spacing scale, motion durations, radius, shadow. The version I run on this site is under 80 tokens total across six categories, which is deliberately small. Every token has to earn its slot against a production file inside two weeks or it gets cut.
The two durability questions for tokens are: can they survive a rebrand, and can they be shared across multiple brands without bleeding. The answer to the first is an abstraction layer (semantic names that reference brand names, not the other way around). I wrote about this in design tokens built to survive the next rebrand. The answer to the second is more interesting: a shared base of architectural tokens with brand-specific overrides, which is the subject of running two DTC brands off one design token base.
The color question gets its own article because accessibility constraints push most DTC brands to a beige fallback that kills visual identity. Keeping brand color without beige accessibility fallback documents the approach I use to get AA contrast without turning everything into sand.
Layer 3: components
Components are what you actually ship. A PDP is a component. A card is a component. An email hero is a component. The question at the component layer is not "how many components do we need" but "how do we hand them off so the code implementation matches the design intent."
When the designer also writes the code (the case for most of the work I do now), the handoff collapses. The tradeoffs of that collapse are worth documenting, which I did in component library handoff when designer also codes. When designer and engineer are separate, the token layer becomes the handoff contract. If both parties read from the same token file, most of the ping-pong goes away.
Typography sits at the interface between tokens and components. The scale is a token set, but the application (what heading level, what line-height, what wrap behavior on mobile) is a component decision. The typography scale from Figma into Shopify Liquid walks through the implementation I use across Shopify builds.
The logo question gets treated as strategy, but it lives at the component layer in practice. Whether you ship a single locked lockup or a flexible system of marks is a component-side decision that has a strategy consequence. The call is in logo lockup vs logo system: which your DTC brand needs.
Layer 4: surfaces
Surfaces are Shopify, Klaviyo, Meta ad library, the printed hangtag, the PDF brand guide. Each surface renders from components. The failure mode at this layer is surfaces that bypass the component system and hard-code their own styles. A Klaviyo template built outside the design system. A printed PDF built in InDesign by a freelancer who did not have the token file.
The cure is a single source of truth that every surface consumes. For the multi-brand engagement I ran last year on the internal brand asset hub, that was a tokens file in the repo plus a generator that rendered the PDF brand guide from the same values (see the brand asset hub case). The printed vendor got a PDF that matched the website because both of them rendered from the same tokens.
The living-doc question is here too. Most brand guides are 60-page PDFs that go stale inside a quarter. I argue the format has to change: killing the 60-page brand guide for a living doc describes the structure I use now, which is code-first documentation that a marketing hire can read in twenty minutes.
When to invest in architecture (and when to wait)
The cost of skipping architecture early is cheap. The cost of skipping it past $1M in revenue is expensive, and the cost of skipping it past $5M is catastrophic. But the cost of building architecture prematurely is also real: a $400K brand refresh for a company doing $300K in revenue is vanity spend. I make the case in rebranding before $1M revenue is usually vanity.
The practical threshold I use: invest in architecture when your team adds a second product line, a second brand, or a second designer. Any of those three is the trigger. Below that threshold, one person holding the whole brand in their head is cheaper than building the system that formalizes it.
“Architecture is what you build when context stops fitting in one head. Everything earlier is overhead you do not need.
”
What this cluster covers
Eleven support articles, each addressing a decision I have made or watched a team make inside the four layers. Some are contrarian (the mood-board article, the rebrand-timing article). Most are operational. The through-line is that every decision at every layer either shrinks or expands the cost of shipping the next thing.
The naming ladder article and the logo system article sit at the strategy-to-component boundary. The tokens rebrand article and the shared token base article sit inside the token layer. The typography scale article, the component handoff article, and the color accessibility article sit at the token-to-component boundary. The living brand guide article sits at the surface layer. The mood board article, the rebrand timing article, and the house of brands article are the strategic framing.
Common mistakes I watch teams make
The first is writing the brand guide before picking the tokens. The guide describes principles that tokens must enforce, but if tokens come second, the guide becomes aspirational and drifts from the code.
The second is treating Figma as the source of truth. Code ships; Figma previews. When both claim to be source, one of them silently drifts, and the surface bug reveals which. I moved my practice to code-as-source and Figma-as-mirror two years ago and have not had a drift incident since. More detail in design tokens that survive a rebrand.
The third is buying a design system tool before building the system it manages. A $200-per-month tool cannot substitute for the architectural decisions you have not made yet. Build the system with the smallest tooling that works, usually a single CSS file and a markdown doc. Upgrade to a tool only when the system exists and the maintenance cost of keeping it in plain files exceeds the cost of the tool.
The fourth is hiring brand and engineering separately when a hybrid hire would produce a better result at a lower total cost. This is a bias toward my own practice, but the case holds empirically: a single person who owns brand and code ships architecture that implements itself. For mid-market DTC operators evaluating that pattern, the creative-tech operator playbook is the adjacent cluster that documents how the role works.
Frequently asked questions
What is the difference between brand architecture and design system?
Brand architecture is the strategy layer (what the brands are called, how they relate, what they stand for). Design system is the implementation layer below strategy (tokens, components, surfaces). You need both, and they have to reference each other. A design system without brand architecture is pretty chrome; brand architecture without a design system is a slide deck that nobody can ship from.
How big should my tokens layer be?
Under 80 for a single DTC brand is my rule. Two brands sharing a base can run up to roughly 120 combined with the shared-base pattern. Anything past 150 tokens for a single brand usually indicates the token layer is absorbing decisions that should live in the component layer instead.
Should I use Figma variables or CSS tokens as source of truth?
CSS. Code is the surface customers see; Figma is a preview of that surface. When Figma is source, every shipped code change silently drifts the Figma file, and the drift compounds quarterly. When CSS is source, Figma is allowed to drift and gets re-synced on a quarterly cadence. One-way sync is stable; two-way sync is not.
When should I bring in a brand consultant vs a design system engineer?
Below $1M revenue, you probably need neither; a single hybrid operator who can do both is cheaper and faster. Between $1M and $10M, bring in whichever layer is breaking first: if naming and master-brand questions are unclear, a brand consultant; if surfaces are drifting and components are reimplemented per page, a design system engineer. Past $10M, both roles become internal hires.
How do I know if my brand architecture is working?
Two tests. The first: can a new designer or engineer ship a new page that looks correct without asking for guidance? If yes, the system is doing its job. The second: when you need to update a color, does the change propagate to Shopify, email, PDF, and ad creative without manual intervention per surface? If yes, the token-to-surface chain is intact. Either test failing is a signal that one of the four layers is weak.
Sources and specifics
- The four-layer model (strategy, tokens, components, surfaces) stabilized after about 18 months of iterative work across nine brand engagements, the most recent being the master-brand rationalization documented in the brand architecture case.
- Token count (under 80 per brand) is an observed working baseline on this site and on the brand asset hub engagement. Token counts above 120 per brand in engagements I have audited consistently correlate with component-layer work that leaked into tokens.
- The code-as-source-of-truth pattern is discussed in the context of the brand asset hub engagement, which served a five-person marketing team at a DTC client. The same pattern works at one-designer scale, as documented in a design system that holds up with one designer.
- The $1M-revenue threshold for formal architecture investment is a pattern across the engagements I have priced, not a published industry benchmark. Exceptions exist for portfolio companies that launch with multi-brand intent from day one.
- Adjacent cluster: the creative-tech operator playbook documents the hybrid role that executes this architecture in practice, and the Operator's Stack is the productized methodology.