Hacker News new | ask | show | jobs
by nkozyra 1186 days ago
> Many companies and tools are built on and rely on this API for their product & daily operations.

Hopefully not their entire product. The first rule is don't build your company on the back of another, but I think the most important part is that if you do use another company, make sure you're fine if they disappear one day.

The last time Facebook made major changes (ostensibly as a response to the Cambridge Analytica stuff, but that was just an excuse) a bunch of people got burned.

My company did too but we always kept ourselves in a place where if it vanished we'd be - at worst - inconvenienced.

This approach came because early on I was burned by Twitter changes that were more impactful.

Most recent Twitter changes prove that even paying for access provides no guarantees.

5 comments

this is easy to say as a comment on HN but unavoidable to a large degree for businesses in the marketing and social media space.
you play in the mud, you're going to get dirty. if your entire marketing company focuses on social, then why that doesn't fall into "all eggs, one basket" concept is beyond me. Sure, it's much easier to get a company rolling when you have to do nothing but use the product of someone else as the core of your business, but why that's not an immediate red flag to someone in that position is something i just don't understand.
This has got to be the most platitudes I've ever seen stuffed in a single comment... I almost want to say it's satire.

But yeah, there's a lot of real valuable businesses built on existential risks. We're currently getting a reminder that our banking system puts all its eggs in the idea not too many people will ask for money at the same time.

Optimizing for black swan events is just generally not good business.

Marketers and customer service need to be able to manage their social accounts, that's a product space which inherently relies on API access to those website. Maybe you wouldn't want to build that product, but clearly somebody will.
Could you just use API's IG app uses itself to manage accounts? And scrape the data you need with GET requests behind a proxy list? Before any public APIs everybody was doing it, is it any hard these days to fall back to regular user API instead of some fancy regulated 'developer-only' API?
Its all rate limited. Inpossible to scrape
Rate limited for what? Totally possible to buy 1000 SOCKS5 proxies for cheap, what's the deal with the limit?
Sorry that’s nonsense. Companies spend hundreds of billions of dollars on FB and IG marketing (presumably because they see a benefit) and are willing to pay companies to help them do it.

Many companies large and small rely on getting most of their business from a single entity, whether that’s the US military, Ford, or contractors working at a local company.

No business opportunity will last forever

> No business opportunity will last forever

Typically, one tries (if one can) to build a business larger than a single opportunity.

Of course, that doesnt need to be said. But tell that to the entrepreneurs that sold businesses that rely on another platform for millions of dollars. If they listened to your advice, they would probably be nowhere as wealthy
Yeah, I don’t think it’s right to say “never try.” It’s more, “never lose sight at how brittle your business is. The other company owes you nothing if it’s not written in a contract. You aren’t a victim when it breaks your business.”
Part of these types of businesses is accepting that risk then, and knowing that despite doing everything right, your business may be unceremoniously shut down because of some PM’s whim. I wouldn’t want to be in that kind of position, but I guess more power to those that do.
Well these are riskier businesses to start for this reason.

I did cage it by saying make sure your whole company doesn't collapse if one API gets shut down.

That is a risk of doing business. If they don't anticipate this kind of thing and build contingencies around it, they are simply bad at business.

"Free market for thee, but not for me" is not a strong argument in any context.

Risk without risk mitigation is just bad business.
You don't understand risk or business if you think a good business mitigates all risks, or even its largest risks.

The biggest risk for a medical company is harming patients. Do they just throw up their hands and stop being a medical company?

The biggest risk for social media firm is the social media they serve through goes down. So what, they throw up their hands and stop being a social media firm?

The biggest risk is losing all money and going out of business. Harming patiences are a cost.
Absolutely not what I am saying, please read up.
I have the same attitude and it is severely restricting my creativity. While I think "don’t build on other peoples APIs", others just launched many tools built on top of Instagram, OpenAI, Twitter and whatnot.

By now I feel like it’s better to build on top of an API, be aware that it might go away one day but make money while it lasts, which can be many years.

Sorry but APIs aren't meant to be broken at anytime. That's what they are for. That is the unwritten part of the so called contracts/agreements.

I do not understand how the idea of not building a company on the back of another is possible. We rely on other companies for deployments, hosting, reporting, monitoring, payments, billing and security etc. Some may be less critical than others but how can you avoid your reliance on other companies at all?

It’s about diversification. Don’t build a company entirely dependent on a single other company that can’t be replaced.

If your payment provider stops offering payments, it’s annoying but not existential. If your whole business is reselling a single artist and they die or switch to a different gallery, you’re done.

Ensure you have a backup supplier that you can switch to.
Very true. It’s a small but very helpful act of looking out for your future self to generalize access to APIs or multiple providers in your codebase via your own concept of accessing a list of service providers can be easily swapped out or added to.
GP's advice generally applies when talking about integrating with a third party API to provide data as a "input" to your business. The things you listed (deployment, hosting, monitoring...) are all after-the-fact concerns, and are generally interchangeable in a way that the API output schema (or systems uptime) for a particular service is not.
> The first rule is don't build your company on the back of another

What's the over-under on # of companies built on AWS?

True. The Twitpic story comes to mind.