Most small teams hear "you need a design system" and quietly panic. The advice usually arrives in a deck shaped for a company with thirty designers, a token pipeline, a Figma library, and a person whose entire job is to keep the library tidy. For a team of six, that is not a system. That is a second job nobody asked for.
There is a smaller, more useful version that fits a small studio, a small product team, or a small in-house design and dev function. It is not less serious. It is just shaped to its size.
We run on one. The site you are reading was built on it. Around forty-four components, a single CSS file of design tokens, no separate library to maintain. It earns its place because it is short on purpose. Everything in it solves a real, repeated problem. Everything not in it stays out.
This piece is about what is actually worth defining when the team is small, what is worth leaving fluid, and why the cost of an unused component is higher than the cost of a missing one.
What a six-person team needs
A design system at this size is mostly a short list of decisions you do not want to make again. That is the test for whether something belongs in it.
Colour is the clearest example. Pick a background, a foreground, three accents, a strong line, a faint line, and a warning. Lock those. Now nobody on the team has to think about which violet to use in a new section, or whether the warning state should be amber or red. The decision is already made.
Type is the next one. A heading scale, a body scale, a line-height rule for paragraphs, a single rule for caps and tracking on the small labels above headings. Now a new page does not start with "what size should this heading be?" It starts with "what does this section need to say?" That is the move.
Spacing follows. A small set of step values, used everywhere. Not a token for every imaginable gap. Enough rhythm that the team can stop arguing about whether the space above a section heading is 48 pixels or 56, because the system has already chosen.
And one rounded-corner rule. Not three.
That is most of the value. The rest is components, and even then, only a few really earn their place.
What deserves a reusable component
The components a small team should build are the ones that get used in three or four places already, where the markup is almost identical, and where rebuilding it from scratch each time would slowly drift the look of the site.
A button. A card. A section header. A hero shape. A pricing strip. A pull quote. A call-to-action block. The handful of shapes that turn up on most pages.
The components that should not exist yet are the ones imagined for a future where you have ten times the team. A modal that supports five variants. A complex tab system. A timeline that nobody has used. A "flexible" hero with eight props because someone was hedging about future needs.
Anything imagined is a future cost. It will need to be styled, maintained, updated, and remembered. If it is not solving a real problem this week, it is a tax the team pays every time it opens the codebase.
What is worth leaving fluid
Section layout is the obvious one. A six-person team does not need a rigid grid rule for the order of blocks on a page. It needs the freedom to compose a page that fits its message. The system gives the team rhythm. It does not give the team a template.
Illustration is another. Lock the style, the palette, the depth, the atmosphere. Do not lock what each illustration has to contain. A system that prescribes every metaphor is a system that produces stock-feeling pages. Better to write a short note about what the illustration should do for the page, and let the artist work out the rest.
Copy is the third. Voice is a system, but the words on each page should be written for that page. A template that fills in the blank is fine for a CRM. It is not fine for a website that someone will actually read.