Begin with recurring decisions
A small system can start with recurring decisions: how text establishes hierarchy, how buttons indicate importance, how inputs show errors, and how content is spaced. Capture those decisions while building real screens. The goal is not to anticipate every component a product might someday need. It is to make current work more consistent and easier to change. A handful of dependable components can be more useful than a large catalog with unclear rules.
Name the role, preserve the source
Use semantic names to describe why a value exists. A surface color tells a contributor more about its purpose than an arbitrary swatch number. When an existing UI package owns the theme, keep it as the source and add only the roles your application needs. Document how those additions relate to the package. That makes future updates easier to reason about and keeps one-off adjustments from becoming a second, conflicting design system.
Test the uncomfortable content
Review components with long titles, empty results, validation errors, narrow screens, and keyboard focus. Real content exposes the limits of a pattern. When a pattern breaks, decide whether to improve the shared component or make an intentional local exception. Record the reason for the exception so it can be revisited. A useful system evolves through those decisions. Its quality comes from supporting the product's actual work with fewer surprises.