You do not need a logo. You need a system.

A client came to us with a good logo. Genuinely good - well drawn, distinctive, appropriate. Their materials still looked chaotic, because a logo answers one question and there are about forty others nobody had answered.

The questions a logo does not answer

• What are the exact brand colours, in hex, RGB and CMYK - and which one is used for a button versus a headline?
• Which typeface for headings, which for body, at what weights and sizes?
• How much clear space around the mark, and what is the minimum legible size?
• What does the brand look like on a dark background? On a photograph?
• What kind of photography - staged or candid, warm or cool, people or product?
• What tone does the writing take - formal, direct, warm?

Without answers, every person creating anything invents their own. Six months later you have four blues, three typefaces and a deck that looks like a different company from the website.

What a system contains

1. 1Logo suite: primary, secondary, monochrome and icon variants with usage rules.
2. 2Colour system: primary, secondary and functional colours with accessible pairings specified.
3. 3Type scale: defined sizes and weights for every level of hierarchy.
4. 4Spacing and layout: a consistent grid and rhythm so nothing is arbitrary.
5. 5Imagery direction: what photography and illustration look like, with examples.
6. 6Component library: buttons, cards, forms - designed once, reused everywhere.
7. 7Templates: decks, documents and social formats your team fills in without a designer.
8. 8Voice guidance: how the brand writes, with real before-and-after examples.

Systems that map to code

When we build a system for a company that also has a product, the design tokens map directly to code variables. The same colour value, spacing scale and type ramp exists in Figma and in the codebase under the same names. Design changes propagate instead of being reimplemented, and the gap where brand consistency usually dies simply is not there.