When to say no to a new component

A component is a commitment

Adding a component looks cheap: an hour in Figma, a day in code. The real cost comes later. Every component has to be documented, maintained, kept accessible, updated when the tokens change and explained to every new person who joins. A system with forty components that people understand is worth far more than one with two hundred that nobody can navigate.

When I say no

I say no when an existing component can do the job with a variant or a small adjustment. I say no when the need appears on a single screen and is unlikely to return. I say no when the request is really about taste rather than function. And I say no, most firmly, when nobody can explain what problem the new component solves that the current ones don’t.

When I say yes

I say yes when the same pattern keeps appearing across different parts of the product, built slightly differently each time. I say yes when a real user need cannot be met cleanly with what exists. And I say yes when a new component will remove more complexity than it adds. Those cases are rarer than people think, which is exactly why they deserve a proper place in the system.

Authority, and the judgement behind it

In the end, this comes down to two things: authority and judgement. Authority, because without a clear final word every request becomes a negotiation and the system drifts. Judgement, because authority alone is just stubbornness. Each decision has to be weighed against the product, the team and where both are heading.

A no is never the end of the conversation. I explain why, suggest how the existing parts can solve the problem and keep the request in mind in case it comes back from elsewhere. If it does, that is usually the signal that the answer has become yes.