The short answer
A client site does not need the forty-token system from a design course. It needs five or six color roles, a type scale, a spacing menu, a handful of global classes, contrast that passes, and one page of handover notes. That is small enough to maintain after you leave, which is the entire point: a design system for client work is judged by how it survives the handover, not by how complete it looks in your file.
Freelancer design systems fail in two opposite ways. The first site has no system at all, so every revision means hunting hex codes through forty elements. The second has a system copied from a big-team tutorial: dozens of tokens, three naming layers, and six months later the client's cousin edits a page and hardcodes everything anyway. The fix for both is the same: a system sized to the person who will actually maintain it.
Why minimal instead of complete?
Because you leave. That is the fact the whole checklist is built around. After launch, the site belongs to the client, an intern, or whoever answers the office email, and every token they do not understand is a token they will work around. Unused parts of a system do not sit there harmlessly; they rot into misleading documentation. Small and enforced beats large and ignored, and on client work that is the only contest being played.
What belongs in the minimal system?
Six items. In build order:
- 1. Five or six color roles. Primary, text, muted text, surface, border, and maybe one accent, named by role, stored as variables. This is the core of design tokens, and it is the difference between "the blue is now teal" taking thirty seconds or an afternoon.
- 2. Three or four font sizes. Body, small, and one or two heading sizes, with their weights and line heights decided once. If a layout seems to need a fifth size, it almost always needs a different weight instead.
- 3. A spacing menu. Six steps on an 8-point base, used for every gap on the site. We wrote a full guide to spacing scales, but the client-work summary is: pick from the menu, never from memory.
- 4. One radius and two shadows. A single corner radius and a small/large shadow pair keep every card and button in the same family. More options than that is how sites drift.
- 5. Global classes for anything repeated. Buttons, cards, section padding: styled once as a class, reused everywhere, per global classes vs ID styles. ID styling is for true one-offs, and on a client site there are fewer of those than it feels like.
- 6. A contrast pass. Body text against its background should reach the WCAG AA ratio of 4.5:1. It takes ten minutes with any free checker, it is the accessibility floor, and light-gray-on-white fails it constantly.
Good to know
Decide breakpoint behavior while you build, not after. For each component, know what it does on a phone before you call it done: retrofitting responsiveness onto a finished desktop site is where client budgets go to die.
What goes in the one-page handover doc?
One page, literally. Four things: the token list with what each is for, where to change them in Bricks (the Style Manager), which global classes style the repeated components, and a two-line walkthrough of the most likely request: "to change the brand color, edit --primary, everything follows." Add who to contact for anything bigger. A client who can self-serve the small changes is a client whose emergency emails you stop getting.
What should you leave out on purpose?
The forty-token palette, the three-layer naming convention, the utility-class-for-everything approach, and any cleverness that needs you present to explain it. These all belong to systems maintained by teams. On a site maintained by a non-designer, each one is a future support ticket with your name on it.
Does AI change this checklist?
It raises the stakes on it. AI tools generate sections quickly, and by default they generate them with hardcoded values: our test of the native Bricks 2.4 AI found not a single CSS variable in the output. Generated work that ignores your tokens un-does the system one section at a time. That is why Bricksfusion Studio generates against your variables and framework: the point of a system is that new work joins it, whoever or whatever produced the new work.
Bottom line
Six items, one afternoon: color roles, a type scale, a spacing menu, radius and shadows, global classes, a contrast pass. Then one page of notes so the next person can drive it. That is the whole system a client site needs, and because it is small enough to survive you leaving, it will still be a system in a year, which is more than most complete ones can say.
FAQ
Questions about this topic
How long does a minimal design system take to set up?
For the checklist in this article, plan an afternoon: an hour or two defining tokens in Bricks, the rest building the first components against them and writing the one-page handover doc. It repays that time on the first round of client revisions.
Do I need a CSS framework for this?
No. Everything in the checklist works with the native variables Bricks has shipped since the 2.2 Style Manager. Frameworks like ACSS or Core Framework sell you a bigger, professionally tuned version of the same idea, which starts to pay when you build many sites per year.
What if the client already has brand guidelines?
Then the color and type decisions are made for you, and your job is translation: turn the guideline values into named tokens and classes so the site actually enforces them. A PDF nobody opens does not keep a site consistent; tokens do.
Will the client understand the system?
They do not need to understand tokens. They need the one-page doc: where to change the brand color, which class styles the buttons, and who to call for the rest. Design the system assuming a non-designer inherits it, because one will.