Ask HN: How Much Reliance on 3rd Party Tech Is Too Much? | Hacker News Reader

Ask HN: How Much Reliance on 3rd Party Tech Is Too Much?

10 pointscharliesdad10 comments

My partners and I came up with an idea for a product and simultaneously started building a product and scouting around the market to see what competition was out there. In that process we found a couple of API's available to use that basically took care of the data processing we needed to be done, so we started using them. So now our product is essentially repackaging these API's* and selling to the customer (with very little of our own proprietary IP). We're finding demand in the market place for the service and signing up customers. We all use 3rd party tech at some level (from AWS up the stack), but this tech goes to the core offering. I'm wondering what people think about businesses like this?

*Our API usage is in compliance with the terms of service, so this is really a business question, not a legal one.

View on HN

Congratulations. What a great way to prove out the usefulness of your service. Minimal effort to fulfill a need.

1. Try to form a relationship with the companies whose APIs you depend upon. Try to find out their plans for the APIs, if they’ll keep them up, if the terms of service will stay okay for you, and if they are likely to become a competitor.

2. Depending upon one, either put your resources into expanding into new areas or replacing the APIs. Expanding would be preferred, but you may need to do both if one of the companies may become a competitor.

Again, sounds like you are in a great spot. More value provided with less effort is always a good thing. Sounds like an eloquent solution. There’s risk, but you recognize it which is important. Focus on growth if you can rather than de-risking the API usage since there are probably a bunch of other unseen risks and growth will help you find these and deal with them. Then gradually de-risk the API usage as you grow.

This is something I often debate as well. On one hand, it allows you to go to market faster. On the other, your business is perhaps less defensible. That said, even if you went out built your own solution from the ground up who's to say someone else wouldn't come along and just piggyback the API you're using now?

As long as you're aware of the potential business risks and are taking at least some steps to mitigate it (or have plans to), you might as well keep adding as much value as possible to further position yourself in whatever market you're playing in.

Focus on the value add, and if you start to reach a scale where pricing becomes prohibitive, great! Now build your own.

If their API changes, well, that's a bit harder to handle. The second you start to see any level of serious traction you'll probably want to either a) lock down a long term contract or b) build a replacement that frees you from this dependancy.

If the company whose api you're selling, goes out of business or changes their service to no longer off the service, can you carry on doing business?

What if they keep offering the service but at 10x the price?

for reference i would say the same about more generic things like app servers, databases, email processors. The moment you rely on a vendor specific thing, you have a dependency on them. Some are unavoidable, and/or low risk. Some are avoidable and/or high risk.

If they pull the API we would be scrambling to find an alternate solution. Likewise, if they 10x the price our business metrics would be turned upside down. So that is a massive risk.

Reinvest any profit you make into weening yourself off the 3rd party tech. Starting with the most mission-critical tech...

Is the API something that would be difficult or impossible for you to replicate on your own? If that's the case, you might have to just stick it out. There's nothing inherently wrong about building a business on top of an API, just there's a higher risk factor involved if say, the company pulls a Twitter and guts the API or goes under etc.

Otherwise, I would advise possibly building a functional clone of the API in earnest (if you have the cycles available to do so) and keep it on the backburner until needed.

The API could theoretically be replicated - its not based on proprietary data from the provider - but it would be a resource intensive effort to do so. And would involve an ongoing to hill climb to match its performance.

Ah, a tricky situation. Honestly if you can, the best choice would be to buckle down and at least replicate some functionality on your own - that way you have at least a safety net if the API is revoked or pricing goes way up

There's definitely value in wrapping APIs - an API is useless to someone who doesn't know any programming. If you can provide an easy interface for non programmers to use the service, that definitely has value, even if the API does all the actual work.

You should aim to have a way to switch on the fly between 3rd Party providers though. On my (small) e-commerce website the payment processor would occasionally have issues with a customer, so I had actually signed up for multiple services that I could switch between at any time. That was useful when one of the providers I'd signed up with ended up getting out of the consumer e-commerce space at short notice.

What I would do:

1. Determine your liability to the customers in the event the APIs are discontinued

2. Assess the risk of the APIs getting shut down

3. Have a contingency plan in place in the event you have to scramble.

Reply on news.ycombinator.com