A food-delivery company running two brands on one design system acquires a third brand. How do you estimate what adding it costs, and when would you decline?
answer
- fixed cost versus recurring cost
- fit to the override surface
- the test matrix grows
- every core release, one more brand
- structural difference is the red line
basics
~20 sEstimate the one-time cost (value set, design library, brand components, migration) and the cost repeated on every core release. Fit decides: a brand inside the override surface is cheap; one needing structural exceptions stays expensive.
solid answer
~50 sSplit the cost in two. The **one-time cost** is building the brand's value set and design library, any brand extension components, and migrating its apps onto the core. The **recurring cost** is what every future core release pays: another set of brand-sensitive visual checks and contrast checks, documentation examples, design review of brand requests, and support for one more team. The deciding variable is **fit to the override surface**. If the acquired pharmacy-delivery brand differs mainly in color, typeface and imagery, it is mostly a value set and the recurring cost is small. If it needs a different navigation model, different component behavior or wide exceptions to locked tokens, every exception becomes a permanent branch the core carries. I would decline — or stage it, running the brand on its own system until its design converges — when the structural differences exceed what the override surface can express without exceptions.
go deeper
Recall that each brand adds ongoing work — testing, review and support — not just a set of colors at the start.
Explain which checks multiply per brand and which do not, and why brand-blind behavior tests stay single while visual and contrast checks grow.
Describe measuring fit by rebuilding key screens with core components and counting exceptions, and staging a brand that does not yet fit.
Own the recommendation: weigh the brand's strategic value against the recurring cost to every existing brand, and set the conditions under which the answer is not yet.
## The decision A food-delivery group runs a restaurant-delivery brand and a grocery-delivery brand on one design system. It acquires a pharmacy-delivery brand with its own app, its own design, and a team used to working independently. Leadership asks the design-system lead: *can it move onto our system this year, and what will that cost us?* There is no formula; the lead's job is to make the costs visible and name the conditions under which the answer is *not yet*. ## One-time costs - **Brand value set** — the pharmacy brand's colors, typeface, radius and imagery expressed through the shared token names, with every color pair checked for contrast. - **Design library** — the brand's version of the shared design library, so its designers design with the real components. - **Brand extension components** — for genuinely pharmacy-only behavior, such as a prescription-upload step, built from core primitives. - **Migration** — replacing the brand's own components in its apps with the core's, screen by screen, while the apps keep shipping. - **Onboarding** — teaching the brand's team the system's contribution, release and support processes. ## Recurring costs These matter more, because they are paid on every core release for as long as the brand exists: | Recurring cost | Why it grows with each brand | |---|---| | Visual checks | Brand-sensitive screens need a baseline per brand, per mode and per platform | | Contrast checks | Every documented color pair is verified for each brand | | Release verification | A core change must be judged safe for every brand's values and extension components | | Documentation | Examples and guidance must hold for every brand | | Design review | More brand requests to evaluate against the locked and overridable groups | | Support | Another team with its own roadmap and questions | Not every test multiplies: behavior tests of brand-blind components run once. It is the brand-sensitive checks that grow by another full set of combinations. ## The deciding variable: fit The cost of a brand is dominated by **how well it fits the existing override surface**: 1. **Fits** — differences are color, type, radius, imagery. Mostly a value set; recurring cost is small and largely automated. 2. **Fits with extensions** — a few brand-only components with clear owners. Moderate cost, contained in a brand layer. 3. **Needs exceptions** — the brand wants to change locked values, component behavior or navigation structure. Each exception becomes a permanent branch the core carries, tests and explains, and it pressures other brands to ask for the same. A useful exercise is to rebuild three of the brand's key screens — the product list, the basket and the checkout confirmation — with core components and the proposed value set, and count the exceptions they need. ## When to say *not yet* - The brand's structural differences exceed what the override surface can express without exceptions. - There is no team to own the brand's value set and extension components. - The core team cannot absorb the recurring cost without dropping commitments to existing brands. - The brand's product direction is undecided, so any migration would be redone. Declining rarely means *never*. Common alternatives are staging the brand: adopt shared token names and a value set first, so its own components start using the system's values; migrate component by component as its design converges; and move it onto the core fully once exceptions are gone. ## Levers that lower the recurring cost - **Test the core with representative themes** plus an extreme stress theme, and reserve per-brand visual checks for brand-sensitive screens. - **Automate contrast validation** of every brand value set in the build. - **Keep the override surface narrow** and grant new overrides for all brands, not as private exceptions. - **Make brand teams owners** of their value sets and extension components, with the core team reviewing rather than maintaining.
- How would you present the cost of the new brand to leadership without inventing precise numbers?Show the one-time work as a scoped list with rough sizes, and the recurring cost as what every core release will additionally require — named checks, reviews and support — tied to the exceptions the screen-rebuild exercise found. Then offer options: full migration, staged adoption through shared token names, or deferral, each with its conditions. Leadership needs the shape of the trade-off, not false precision.
- Why can a single exception for the new brand end up costing more than the whole value set?A value set is data that automated checks cover. An exception is a permanent difference in behavior or structure: it needs its own tests, it must be reconsidered on every core change, it complicates documentation, and other brands cite it to ask for their own. Its cost recurs on every release, whereas the value set is built once.
saying these in an interview costs you the question
- Once the core exists, every additional brand is essentially free.
- Adding a brand only costs the time to write its color values.
- Every test in the suite must run once per brand.
- If leadership wants the brand on the system, the system lead should never push back.
- Grant the acquired brand exceptions now and remove them later; exceptions are temporary.