When should a component be reusable vs a one-off?

A pattern earns componentization when it recurs or is genuinely likely to recur and benefits from a single source of truth, and a truly singular case is better built directly. The deciding test is real or likely repetition, not a wish to systematize everything. Reuse is the entire justification for the cost of abstraction, so the question to answer honestly is whether this thing will actually be used in more than one place. Build the component when reuse is real, not when it is merely imaginable.

The reasoning is that a reusable component is not free. It costs design to make it general enough to fit several contexts, costs documentation so others can find and use it correctly, and costs ongoing maintenance as it absorbs new cases. That cost pays off handsomely when the component is reused, because a single source of truth means one change updates every instance and consistency comes for free. But when something is built as a reusable component and then used exactly once, you have paid the full abstraction price and received none of the return. The instinct to make everything reusable for consistency feels disciplined, yet it abstracts prematurely and leaves you maintaining generality nobody needs.

A concrete example sharpens the call. A form input, a button, a card, a navigation item: these recur across nearly every screen, and componentizing them is obviously right, because the alternative is dozens of slightly different inputs drifting apart over time. Now consider the celebratory illustration and copy on a one-time onboarding completion screen, a layout that exists in a single place and is unlikely to appear anywhere else. Wrapping that in a flexible, configurable component, with props for every variation it might theoretically need, is effort spent generalizing something that will never be general. It is faster to build, easier to read, and cheaper to maintain as a direct, specific piece of design. Same instinct toward tidiness, opposite outcome: one repetition rewards abstraction, the other punishes it.

One place the rule bends is likely repetition, because the test is not only about what recurs today. Sometimes you can see with real confidence that a pattern will spread soon, for example a status badge introduced on one screen as the first of several planned statuses across the product. Building it as a component up front is justified there, because the repetition is genuinely foreseeable, not merely possible. The discipline is honesty about that forecast. Almost anything could recur in principle, and treating every could-recur as a will-recur is how premature abstraction sneaks back in. Likely means you have a concrete reason to expect reuse, not a vague hope that systematizing now will pay off later.

There is also a healthy middle path that keeps you from over-committing. When you are unsure whether a pattern will recur, you can build it directly first and extract a component later once a second and third use actually appear. Promoting a proven pattern into a component is cheap and safe, because by then you know exactly what it needs to flex on. Guessing at reusability before any repetition exists is where you waste effort and bake in the wrong flexibility. Designing for reuse you do not yet have tends to produce components that fit no real case well.

So decide by actual repetition, not by an urge to systematize. Componentize patterns that genuinely recur or that you have solid reason to expect will recur soon, and build true one-offs directly without apology. For anything in between, build it directly and extract it the moment a real second use appears. Before turning a piece into a reusable component, name where else it is used or will demonstrably be used. If you cannot point to that, you are about to abstract a one-off.