Design systems when you're a team of one

The conventional wisdom on design systems was built for teams, not individuals. Token pipelines, Storybook, semantic versioning, contribution guidelines — all of it adds friction that solo builders can't afford.

What actually works when you're a team of one is simpler than you'd think: a single globals.css with CSS custom properties, a handful of utility classes for the patterns you repeat most, and the discipline to not deviate from them.

For the muvevi design system, I have exactly two themes — public and dashboard — each defined as a set of CSS vars under a data-theme attribute. Tailwind's @theme inline block maps those vars to utility classes, so the same Tailwind class (bg-background, text-foreground) resolves differently depending on which theme is active.

The key discipline is restraint. I have one brand colour (amber, #F5A623) that only appears on hover and interactive states. One font for headings (Patua One), one for body (Inter). Zero border radius on the public site. These constraints make every new component consistent by default — there's nothing to decide.

For components, I only abstract something when I've written it three times. Copy-pasting a button implementation twice is fine. The third time, I extract it. This prevents premature abstraction — the shape of the right abstraction only becomes clear with a few concrete examples.

The parts of a "proper" system that do translate to solo work: naming tokens semantically rather than by value (--accent-amber vs --color-f5a623), keeping animation easing curves in one place, and having a clear hierarchy for where components live (src/components/public vs /dashboard vs /ui).