Here is something that does not show up in any sprint review or quarterly roadmap: the slow accumulation of duplicate components on a website that has been running for more than three years.
It starts innocently. A developer builds a banner module in 2019 for a campaign landing page. It works, it ships, everyone moves on. The next year, a different developer joins the team and needs a banner for a product page. They do not know the 2019 banner exists, or they find it but it does not support the CTA button they need. So they build a new one. By 2022, a third developer creates "Banner v3" because the first two do not handle responsive images the way the new design system requires.
Nobody is doing anything wrong. Each decision makes sense in isolation. But zoom out and look at the full module inventory three years later, and the picture is different.
This is component sprawl. And in CMS platforms like HubSpot, it is almost invisible until something forces you to look at the whole system at once.
Why CMS platforms make this worse
Traditional web applications have build systems, component libraries, design systems, linting rules, and import patterns that naturally surface duplication. If two React components do the same thing, there is a decent chance someone will notice during a code review or a dependency audit.
CMS platforms work differently. Modules in HubSpot are created through the Design Manager or the CLI, and they live in a flat list. There is no built-in dependency graph. There is no tool that says "this module is functionally identical to that one." There is no component registry that developers check before building something new.
The result is predictable. A site that has been actively maintained for four or five years ends up with three different accordion modules, four hero sections, five banner variants, and two footer components that produce identical output.
We have seen this firsthand. During a recent content architecture audit, a large enterprise HubSpot site turned out to have 166 modules. The team responsible for the site estimated they had about 40. That is not a rounding error. That is a four-to-one gap between perception and reality.
The trigger that makes it visible
In daily operations, module sprawl causes no immediate symptoms. Pages render. Content editors can still publish. The design looks right to visitors. Nobody has a reason to count the modules.
The trigger is almost always a migration or a major redesign. The moment someone needs to map every component from the old system to a new one, the sprawl becomes a blocking problem.
Each duplicate module is a mapping decision. Each variant needs to be evaluated: is this meaningfully different, or is it the same thing with a slightly different field structure? Can three accordion components be consolidated into one configurable component, or do they serve genuinely different purposes?
This is architecture work that teams expect to take days but ends up taking weeks, entirely because nobody maintained a clean inventory along the way.
What governance actually looks like
Component governance does not require complex tooling. It requires a process and a habit.
At minimum, it means maintaining a living inventory of every module in your CMS. Not in someone's head. Not in a wiki that was last updated eighteen months ago. An actual, current list that developers reference before building anything new.
It means having a rule: before creating a new module, check the existing inventory. If something similar exists, extend it. If the existing module cannot handle the new use case, document why a new one is needed and who approved the decision.
It means running periodic audits. Not waiting until migration day to discover you have five banners. Running a quarterly check that counts components, flags duplicates, and consolidates anything that has drifted.
For HubSpot sites specifically, this is harder than it should be. HubSpot does not provide a single view of all modules with their usage data out of the box. Building that visibility usually requires pulling the data through the API or using a tool that can surface the full inventory.
We wrote about the broader architecture problem, including how a 166-module site got consolidated down to 40 during a migration, on the Smuves blog. The consolidation process is worth understanding if you are working on a site that has been around long enough to accumulate this kind of debt.
The developer takeaway
If you work on a CMS that has been in production for more than two years, assume you have more components than you think. Run the count. If the number surprises you, that is the signal to start governance now rather than during a future migration.
The cost of counting and consolidating proactively is a fraction of the cost of discovering the sprawl when you are already committed to a migration timeline and budget.
Component sprawl is a governance problem, not a technology problem. And governance problems only get solved when someone decides to start tracking.
