What “building a system” actually means in a digital product
A system is the set of decisions that connect strategy, design, and engineering so the product keeps working when conditions change.
When we say ‘we build systems, not websites,’ people nod politely and assume we mean design systems — colour tokens, component libraries, a Figma file with neat labels. Those exist, but that isn’t what the phrase points at.
A system, in the sense we mean, is the connective tissue between the three parts of a product that almost never talk to each other: the business decisions, the user-facing design, and the code underneath. When those three are aligned, everything feels calm and the product ages well. When they’re not, every small change creates a cascade of arguments.
Most products aren’t systems. They’re stacks.
A stack is what happens when each layer is built without reference to the others. Marketing picks a new campaign headline. Design ships a new section. A developer adds a new component. Each decision is defensible on its own. Put them together over eighteen months and you have a product that contradicts itself — different voices on different pages, UI patterns that mean different things in different flows, content that refers to features that were quietly removed.
A system is the opposite: a small set of shared decisions that everyone — writer, designer, developer, founder — can point to when they’re choosing what to do. Not a rulebook. A reference point.
“A system isn’t a library of components. It’s a library of decisions.”
The three layers a system connects
Strategy: who the product is for, what it helps them do, what it refuses to do. This is usually written in a pitch deck and then forgotten. A system keeps it alive at the level where decisions actually happen.
Design: the visual and interaction language — not just colours and type, but the rhythm, the pace, the posture the product takes toward the user. Is it polite? Direct? Playful? A system makes that answer consistent across every surface.
Engineering: how the product is built — which patterns are reused, which are one-offs, where the seams are. Engineering choices quietly shape what future features are cheap versus expensive. A system surfaces those trade-offs early instead of discovering them mid-sprint.
What it looks like day-to-day
The honest signal that a system is working is boring: people stop arguing about small things. A marketer doesn’t wonder whether to invent a new CTA style — there’s one that fits. A designer doesn’t reinvent a card component for the fifteenth time — they reach for the existing one. A developer can estimate a new feature in hours instead of days because 80% of it already has a home.
The signal that it isn’t working is equally obvious: every feature takes longer than it should, and nobody is sure why. The answer is usually that each person is re-litigating a decision that was never actually made.
Why it matters commercially
Systems compound. Every new page, feature, campaign is faster and cheaper than the last, because the decisions are already made. Stacks do the opposite: every new thing is slower, because each one renegotiates what the product already is.
Over a year, the difference shows up as either momentum or exhaustion. We’ve watched small teams with a proper system outship much larger teams who were constantly rebuilding the same wheel.
When we say we build systems, that’s what we mean. Not a component library. A set of shared decisions thin enough to remember and strong enough to scale.