There’s a decision that sits in front of almost every growing product organization, and almost everyone puts it off until it’s expensive. The decision is whether to stop and build shared, reusable pieces, or to let each team keep building its own version of everything. It gets deferred because the cost of deferring it is invisible right up until the moment it’s enormous.

Here’s how it usually goes. You have a few teams. Each one is moving quickly, shipping its own search, its own scheduling flow, its own settings screen. Individually, every one of those decisions is reasonable. Building shared infrastructure would slow any single team down this quarter, and no single team wants to be the one that volunteers to go slower. So nobody does. The duplication compounds quietly. Then one day someone asks why a simple change has to be made in five places, why the product feels inconsistent, and why every new launch takes longer than the last. That’s the bill arriving, and by then it’s much bigger than the decision would have cost up front.

The research on this is unusually blunt. Nielsen Norman Group, which has studied design systems across many organizations, reports that teams with mature design systems see meaningfully faster product development and a real reduction in design-related technical debt. Other analyses put the technical-debt reduction from a mature system in the range of half to three-quarters of what teams were carrying before. And the consistency payoff isn’t only about aesthetics or engineering hours: McKinsey has found that companies with high design debt, the kind you accumulate when every team builds its own divergent version of the same thing, carry noticeably higher customer support costs, because inconsistent interfaces confuse the people using them. The duplication you can’t see on the roadmap shows up on the support line instead.

I hit this directly at a healthcare company building across five product pillars, each one staffing up to build the same core experiences its own way. The politically easy move was to let it continue. Everyone was busy, everyone was shipping, and proposing a shared component library meant asking teams to invest in something that wouldn’t pay off in their current sprint. I made the case anyway, because the trajectory was obvious: five divergent versions of the same thing, each one a future maintenance burden and a source of inconsistency the user would feel.

The library covered the pieces every pillar actually needed, search, match, scheduling, virtual visits, health assessments. It cost real time to build. Then it paid that time back on every launch that followed, because nobody was rebuilding the same wheel, and feature adoption went up 33 percent once the experience was consistent enough for users to trust. The payoff was real, but it only existed because someone made an unpopular decision before the pain was acute.

Here’s the part I actually want to argue. The reason this decision gets deferred isn’t ignorance. Everyone can see the duplication. It gets deferred because the incentives are misaligned: the cost of building shared infrastructure lands on one team now, and the benefit is spread across every team later. That’s a structurally hard trade to make from the bottom up, which means it usually doesn’t happen unless someone with a cross-team view forces the conversation. The organizations that get it right tend to fund the shared system deliberately. One widely cited example is Shopify’s Polaris, where a small dedicated team enables a far larger population of developers to work efficiently, a rounding error of overhead buying leverage across everyone else.

So if you’re the person with that cross-team view, forcing the conversation is the job. Not when the duplication becomes unbearable. Before it does, when the argument is still abstract and unpopular and easy to wave off. The best time to make the reusable-component decision is exactly when it feels premature. The second-best time is the moment you notice you’re already paying for having waited, in support tickets, in slowed launches, and in the quiet tax the research keeps measuring.

Sources: Nielsen Norman Group research on design system maturity; McKinsey & Company on design debt and support costs; Shopify Polaris design system.