Tend to agree on third party dependencies. They're a useful leg up if you're just prototyping, testing an idea, or generally groping around for product/market f

Tend to agree on third party dependencies. They're a useful leg up if you're just prototyping, testing an idea, or generally groping around for product/market fit, but I'm not in love with them as a long term solution - certainly not for anything that's core to your product or service. Too many potential pitfalls: - If their service goes down, you may go down too, or you have the added complexity of gracefully handling the situation when they're down - You have no control over their roadmap... which means you might suddenly get a bunch of non-value-adding but totally essential work dropped into your backlog, and perhaps at short notice, because of changes they make - Perhaps they go out of business or, for whatever reason shut down their service: again, congratulations, you've just got a load of work you didn't bank on getting in the way of delivering your own roadmap I think most of us have probably seen multiple examples of the above, if not at first hand, then posted on HN or elsewhere on the web. I'm not an NIH kind of guy but I do tend to prefer libraries, or co-located installs for long-term dependencies. That way at least you can manage migrations and updates according to your own agenda rather than somebody else's.