It’s generally good practice among developers to break things down into small, independent, reusable components. But, like all good things, it can become problematic when taken too far too soon.
Here’s an example from poketto.me:
A few weeks ago, I introduced colored tags. Users can choose one of eight colors for each tag to help them quickly find what they’re looking for and organize their tags visually. (Personally, I use one color for all location-related tags, another for tech topics, etc.)
To support this, I built a small color picker component — Exhibit A.
At the time, I had a hunch that I might need it again somewhere else, so I didn’t bake it directly into the tags page. Instead, I tried to make it reusable for future use cases. The problem? I had no idea what those future use cases would actually be — or how they’d work. So I ended up with a “reusable” color picker that was still tied to a single usage.
Fast forward a few weeks: I started working on the podcast feature, where users can create multiple podcast feeds. When sending saved content to one of these feeds, it’s easier to click the orange thing than to read the label – Exhibit B. For example:
🟧 My “Travel & Geography” feed is orange.
🟦 My “Tech & Industry News” feed is blue.
🟩 My “Nature & Sustainability” feed is green.
The color also determines how the feed appears in the podcast, and it’s nice to give them unique cover images for quick recognition – Exhibit C.
Naturally, I turned to my trusty color picker. But it turned out to be completely unsuitable.
Why?
On the tags page, the color picker simply selects one of several predefined colors (stored as hex strings). In the podcast settings, though, the “color” is actually a pointer to a cover image. Mapping hex strings to cover template filenames? Not exactly ideal.
The solution:
I refactored the color picker, added a dedicated color service, and rewired code on both the tags page and the podcast settings page. I ended up reusing as much as possible — but the extra work I originally put into making a “generic” color picker was wasted.
Lesson learned: I could have saved a couple of hours by keeping it embedded in the tags page and only generalizing later, once the second use case actually arrived.