Several teams working across different parts of the product had each independently invented their own version of the same handful of custom utility classes, subtle spacing and text-truncation helpers that Tailwind doesn't ship by default. One team called their two-line text truncation helper `truncate-2`, another had built essentially the same thing as `line-clamp-custom`, and neither team knew the other's version existed until a routine code review surfaced the duplication almost by accident.
Consolidating them into a small internal Tailwind plugin, shared through our design system package, removed the duplication and gave every team the same utilities with consistent naming going forward. Writing the plugin itself was straightforward, Tailwind's plugin API is well documented and the utilities in question were simple enough that most of them translated into a plugin function within an afternoon, but auditing the codebase to find every existing variant of each utility, so we could actually replace them rather than just adding a third option alongside the two that already existed, took longer than writing the plugin did.
We ended up finding four different truncation-related utilities and three different variations on a consistent focus-ring style across the codebase, more duplication than we'd expected going in. Standardizing on one version of each meant a few small visual differences in edge cases, slightly different truncation behavior at certain container widths, that needed sign-off from design before we could safely replace every usage rather than just picking whichever version looked most common and moving on.
The plugin now ships as part of our shared design system package alongside our color and spacing tokens, versioned and published the same way, so any project pulling in the design system gets the utilities automatically rather than needing a separate installation step. New utility requests now go through a short review process before being added to the shared plugin, specifically to avoid ending up back in the same situation where a team invents a one-off solution rather than checking whether a shared utility already covers their need.
Documenting each utility's intended use case turned out to matter almost as much as writing the plugin code itself. Early on, a couple of teams started using the new shared truncation utility in places it wasn't really designed for, a multi-line card description where the design actually called for a different line-clamp value than the default the utility provided, which nearly kicked off a fresh round of one-off overrides that would have partially undone the consolidation. Adding a short usage note to each utility's entry in our internal documentation, including which scenarios it's meant for and which it isn't, has kept that kind of drift from creeping back in since.
We're now applying the same review-before-you-build-your-own-version process to a couple of other categories of small internal helpers, mostly shared animation easing curves and a few common flex layout patterns, since the Tailwind plugin consolidation made it clear this pattern of quiet duplication wasn't unique to spacing and truncation utilities.