The phrase "design system" tends to summon images of enormous component libraries maintained by dedicated teams. That version exists, but it is not the useful one for most companies. For a small team, a design system is simply the set of decisions you have made once so that nobody has to make them again — and it can be genuinely small.
Start with tokens, not components
The highest-return decisions are the smallest ones: a fixed colour palette, a spacing scale, a type scale, a radius scale and a shadow scale. Once those exist and are used, work produced by different people starts to look related even before any shared components are built. Most visual inconsistency traces back to arbitrary values, not to missing components.
Specify states, not just appearance
The gap that costs the most development time is not what a button looks like — it is what it does when it is focused, loading, disabled, or when the list behind it is empty and the request behind it failed. Designs that stop at the happy path push those decisions into implementation, where they get made inconsistently and under time pressure.
- Default, hover, focus, active and disabled for anything interactive
- Loading state for anything that waits on a server
- Empty state for any list, table or result set
- Error state, with wording that tells the user what to do next
Include both text directions from the start
If the product will ever be bilingual, the system should account for it immediately. Using logical properties — start and end rather than left and right — costs nothing at the beginning and avoids a full audit later. Retrofitting direction support across an established component library is substantially more work than building it in.