Many systems market themselves through their easy to use API.

"All you have to do is invoke this function, and it works!", they say.

A common story is one of a team adopting an easy to use system, then feeling blindsided once the system is entrenched. They find themselves taking more time to fix the system than it would have taken to build a home-grown implementation specific to their use case. Or more frustrating, they find themselves paying a lot of money to pay a support contract so they can reclaim their team's time spent troubleshooting.

If you are evaluating whether to use a third party system, really what you're looking for is for somebody else to absorb costs, so that you don't need to. That is all variants of cost, not just development cost.

cost = upfront cost + ongoing operational cost

the work to fix it when it breaks =
    (one time) the time to learn how to fix it
  + (recurring) the time to make changes in accordance with new learning

Most teams neglect to consider the ongoing operational cost of systems when evaluating what to deploy.

How do you protect yourself from this? Don't rush to adopt. Ask yourself some questions first.

• How does this work under the hood?
  • Is the system significantly more complex than it really needs to be for my own use-case?
  • Is it likely that I'm going to have to understand deep internal details in order to troubleshoot it?
• How much operational guidance is baked in?
  • Does it come with automation, or does it expect me to figure out how to do that?
• Is there a way I can utilize this system so that it does not become too entrenched, and I can replace it with another solution if it doesn't work out?

Third party solutions are legitimate short-cuts, but they are not free. If you don't understand what you're working with, then down the road it can cost you more than it would have to develop it yourself.