Why 'design system' is the wrong goal
Most solo designers and small teams fail at design systems because they build for scale they do not have yet. They create a full token hierarchy, component documentation site, and contribution guidelines before shipping a single feature. The right goal for a solo project is a 'micro design system' — the minimum set of decisions that prevents visual inconsistency and developer rework. That means: a token file with 12 to 20 CSS variables, 8 to 12 reusable components with typed props, and one source-of-truth file that maps decisions to their rationale. Everything else is premature.
Tokens before components — always
The single decision that prevents the most rework is separating values from usage. Define colour, spacing, radius, and shadow as CSS custom properties or a design token file before creating any component. When a client asks for a brand refresh and you have tokens, you update 12 variables. When you do not, you hunt down hardcoded values across 40 files. I structure tokens in three layers: primitive values (the raw colours and numbers), semantic aliases (what they mean — background, border, interactive), and component-level overrides (only when necessary). The semantic layer is where the real thinking happens.
The five components that cover 80% of UI work
For most B2B product and marketing interfaces, five component families cover the majority of design decisions: Button (with clear variant and state structure), Card/Panel (surface with consistent padding and border behaviour), Form Field (input, textarea, select — with error and focus states), Tag/Badge (status and category labelling), and Typography scale (heading hierarchy and body copy with responsive sizing). If these five families are well-built and token-driven, everything else is composition, not invention. I build these first on every project before touching any page layout.
Documentation that actually gets used
Long documentation files are not read. The documentation format that survives a solo project is inline: comments in the token file explaining decisions, prop types in TypeScript components, and a single design-decisions.md in the repo root that lists every non-obvious choice and why it was made. On client handoffs, I record a 10-minute Loom walkthrough of the token structure and component library. This is used far more than any written guide because it shows the system being used in context, not described in abstraction.