Reuse count isn't the metric that matters
A component used in five screens with five slightly different boolean flags bolted on isn't reusable — it's fragile in five places at once. True reusability is measured by how a component handles a new, unanticipated requirement: does it extend cleanly, or does it need a new prop, a new conditional branch, and a new set of tests every time a sixth module needs something slightly different?
Across six-plus feature modules — client management, projects, documents, time tracking, reporting, billing — that difference compounds fast. A brittle shared component becomes the thing every team is afraid to touch.
What actually makes a component hold up
Composition over configuration
A `Card` with a content-projection slot handles infinite future layouts. A `Card` with `showHeader`, `showFooter`, `headerVariant` props hits a wall the moment someone needs a layout the flags didn't anticipate.
Props describe intent, not implementation
`variant="danger"` ages better than `backgroundColor="#ef4444"`. The first survives a rebrand; the second requires updating every call site.
A boolean prop is often the first symptom
One boolean flag is fine. Three or four on the same component, each toggling unrelated behavior, usually means the component is doing two jobs and should split in two.
Document the contract, not just the props table
What the component guarantees — does it manage its own loading state? does it emit on every keystroke or only on blur? — matters more to a consuming team than an auto-generated prop list.
Extract on the second use, not the first
A component generalized after one use case is usually generalized wrong — it encodes assumptions from that single screen. The second real use case is what reveals the actual shared shape.
Give shared components an owner
Across six modules and multiple teams, an unowned shared component accumulates inconsistent changes from whoever touched it last. A named owner who reviews changes keeps the API coherent.
The real test: the request you didn't design for
Every shared component eventually gets a request nobody anticipated — the billing module needs the data table to support inline cell editing, or the reporting module needs the modal to support a non-standard footer layout. A well-designed component absorbs that through its existing composition points. A poorly designed one needs a new prop, a new conditional path, and a new set of edge cases to test.
That moment is the real measure of whether a component was reusable or just reused. Treat it as a signal: if the fix is a clean composition, the design held. If it's another boolean flag, that's the debt showing up.
The takeaway
Reusability isn't how many places a component is used — it's whether it absorbs the requirement nobody anticipated through composition, or needs a new boolean flag every time. Favor content projection over configuration flags, extract on the second real use case rather than the first, and give shared components a named owner once multiple teams depend on them.
Let's talk about your frontendRelated reading
Architecture
The Case for a Thin Wrapper Layer Around Every UI Library
Angular · Theming
PrimeUIX Theming in Practice: Customizing a Design System Without Forking It
CSS · Architecture
A 7-1 SCSS Architecture That Survives Multiple Teams
See this component system applied in production on the Compito case study.