What do you do when a tool your product depends on stops being maintained?
by•
In client work I have seen it many times: a plugin, library or service that a site quietly depends on stops getting updates. Nothing breaks on the day, so it is easy to ignore, until a new version of something else makes it fail.
The options I know are replacing it early, forking it, wrapping it so it can be swapped later, or accepting the risk and watching it. Each one costs time that never shows up in a launch plan.
How do you notice that a dependency is going quiet, and what was the last one you replaced? What made you finally move?
10 views
Replies
Wrapping it is the one I'd pick every time, and it paid off for me twice already. Every music engine in my backend sits behind one small interface, so a vendor is one adapter file. The first engine I wired never composed a single song for me, it turned out to need a paid plan, so I swapped it for another vendor that tested better and cost a fifth of the price. That was an adapter, not a rewrite. And because the shape is the same, a second engine sits behind the first as a fallback, so a vendor having a bad day doesn't mean my users do. What made me this careful was my previous app, which depended on an unofficial API and died the day it stopped working.
It happened to me with a browser called Sidekick. I bought a lifetime license in April 2024 and used it every day to keep several Gmail accounts open side by side. In summer 2025 I learned it was shutting down, and the makers had announced the sunset before I even bought it. The team was acquired and moved on to a different browser.
That's what finally made me move. I built my own replacement. Not something everyone can do, but for a tool I use every single day, I'd rather own it now.