Building a Brand From Scratch: What Survives Contact With Engineering
Most brand guides stop at the logo. This one continues into the part that decides whether any of it survives: the handoff to the people who have to build it.
Updated — rebuilt as a design-engineering guide — what happens to a brand once it has to be built
Contents8 sections
- What has to be decided before any visual work?
- Why does the visual identity keep drifting after launch?
- Which states does a designer have to specify?
- Is accessibility a design decision or an engineering one?
- Does performance belong in a brand conversation?
- What should the handover actually contain?
- Common questions
- The short of it
A brand identity is usually judged on the day it is presented, in a deck, at full size, on a good screen, with nobody using it. Its real test comes months later, when someone who was not in that room has to build a disabled state for a button nobody specified and picks something that looks approximately right. This guide is about that second moment, because that is where brands actually get decided.
What has to be decided before any visual work?
Three questions, and they are strategy rather than design. Skipping them does not stop a visual identity being produced — it stops anyone being able to say whether it is right, which turns every later review into a matter of taste.
The three that constrain everything downstream
- Who is the customer, specifically enough to exclude someone? A brand for everyone provides no constraint, and a constraint is the only thing that makes a design decision checkable.
- What is the one thing you want to be known for? Not a list. One. Everything in the identity either carries it or is neutral to it.
- Where will people actually encounter this? An identity built for a landing page and an identity built for a dense B2B application are different objects. Decide which one you are commissioning.
Why does the visual identity keep drifting after launch?
Because it was delivered as a document rather than as a system. A guidelines PDF describes intent. A codebase needs decisions, and it needs one for every case — including the dozens nobody drew. Where the document is silent, the implementation improvises, and six months of improvisation is what people mean when they say the brand has drifted.
| Delivered as a document | Delivered as a system |
|---|---|
| A palette of six brand colours | Semantic tokens — surface, border, text-muted, danger — with the hex values behind them |
| Two typefaces and their weights | A type scale with line heights, applied by role rather than by size |
| Spacing described as 'generous' | A spacing scale everything snaps to, so nothing is off-grid by eight pixels |
| Button styles, in three sizes | A button component with every state: default, hover, focus, active, disabled, loading |
| Screens, at desktop width | Components, at every width, with the wrapping behaviour decided |
Which states does a designer have to specify?
More than most handovers contain. A mockup shows a product working perfectly with realistic data, and almost none of the engineering effort goes there. The list below is what we ask for before starting a build, and the parts that are missing are where the design will be quietly invented.
Specify each of these, for every meaningful component
- Hover and active — including on touch devices, where hover does not exist
- Focus — visible, high contrast, and not the browser default sitting awkwardly on a custom control
- Disabled — and whether it is even the right pattern, since a disabled button with no explanation is a dead end
- Loading — skeleton, spinner or optimistic, decided rather than defaulted
- Empty — the first screen every new user sees, and the one most often left undesigned
- Error — what it says, where it appears, and whether the user can recover without losing what they typed
- Long content — the name that is forty characters, the list with two hundred rows
Is accessibility a design decision or an engineering one?
Mostly a design one, and it is decided at the moment a palette is chosen. Contrast ratios, focus visibility, target sizes and whether colour is the only carrier of meaning are all settled before an engineer opens an editor — and retrofitting any of them means revisiting the identity, which is why it rarely happens.
The scale of the downside, in the US
- 3,117
- Federal web-accessibility filings, 2025
- 64%
- Of companies sued had revenue under $25m
- ~45%
- Of suits targeted a previously-sued company
+27%
Seyfarth Shaw; over 5,000 including state courts (UsableNet)
UsableNet, Jan 2026 — vendor research, but the pattern is well supported
1,427 filings — fixing it once is not the end of it
Does performance belong in a brand conversation?
It does, because it is experienced as quality and attributed to the brand. Deloitte's study for Google — 30 million user sessions across 37 brands — found a 0.1 second improvement in mobile site speed lifted retail conversions by 8.4% and average order value by 9.2%. A design that requires four custom typefaces and a full-bleed video is making a performance decision, whether or not anyone in the room says so — the Next.js agency shortlist covers where those decisions land in the build.
What should the handover actually contain?
Four artefacts, in this order
Tokens, named by role
--surface,--surface-raised,--text-muted,--danger— not--brand-blue-2. Role names survive a rebrand; colour names describe a decision that is about to change and then lie about it forever.A component inventory with states
Every component the product needs, with the states from the checklist above. This is the actual deliverable; the screens are illustrations of it.
The rules that are not visual
Date and number formatting, capitalisation in labels, how errors are phrased, what the product calls the user. These get decided by whoever writes the first form, and then inconsistently by everyone after.
A written note on what is deliberately undefined
The most useful page in any handover. Saying "we have not designed the data table yet, use the component library default" prevents an improvisation that nobody will ever revisit.
Common questions
Do we need a full brand identity before building the product?
No, and attempting one usually delays the thing that would tell you whether the product is worth branding. A palette, a type scale, a spacing scale and a logo are enough to build something coherent. The full identity is better commissioned once you know who the customer turned out to be.
Should we use an off-the-shelf component library?
For most early products, yes — and then theme it. The value in a design system is consistency and accessible defaults, and both come free with a mature library. Building components from scratch is a decision to spend your engineering budget on buttons, which is only correct when the buttons are the product.
How do we stop the brand drifting after launch?
Make the correct thing the easy thing. If the token exists and is named sensibly, people use it; if they have to find a hex code in a PDF, they approximate. Drift is almost never a discipline problem — it is a problem of the right answer being harder to reach than a near-enough one.
Who should own the design system once the agency leaves?
A named person, and the answer should exist before the engagement ends. An unowned system decays at the speed of its first urgent deadline, and nobody notices until the product looks like four different products.
The short of it
Brands are not lost in a redesign. They are lost one undefined state at a time, by people doing their best with an incomplete specification and a deadline. Specify the states, hand over tokens rather than a document, and write down what you deliberately left undecided — those three habits preserve more of an identity than any amount of guideline prose.
Researched and drafted with AI assistance, reviewed and edited by Syed Arham before publication. Every statistic is linked to its source. Our own work and pricing claims come from our delivery record. How we write and correct
