
Ask HN: How Much Reliance on 3rd Party Tech Is Too Much? - charliesdad
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&#x27;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&#x27;s* and selling to the customer (with very little of our own proprietary IP). We&#x27;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&#x27;m wondering what people think about businesses like this?<p>*Our API usage is in compliance with the terms of service, so this is really a business question, not a legal one.
======
poof131
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.

------
austinhulak
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.

------
stephenr
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.

~~~
charliesdad
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.

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

------
yolesaber
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.

~~~
charliesdad
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.

~~~
yolesaber
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

------
SyneRyder
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.

------
theaccordance
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.

