Building software on top of someone else's web api is a really, really bad idea. If you don't control the system it runs on, then you are completely at the mercy of someone else's business. If they go broke, your software goes down. If they have a technical problem, your software goes down. If they decide to change some aspect of their software, your software goes down. Please, think twice before you build your businesses out of this deck of cards.
The thing is, if you're building a startup, you want to deliver value to your customers as quickly as possible ... you know, so you don't die.
Customers don't care whether you used an API or rolled the functionality yourself. For an early stage startup, implementing or troubleshooting back-end functionality you could have outsourced to an API is, to a first approximation, a waste of time.
If you don't control the system it runs on, then you are completely at the mercy of someone else's business. If they go broke, your software goes down.
but, couldn't you make this argument about many things? your company's payment gateway? your bank? ISP? server host? etc.. your business will hit the breaks if there are any major hiccups with the providers of any of these services.
i mean, its contextual, of course. if you've written a twitter app, its different. its not an app being built with the help of an api, its an app being built specifically for an api. but a single business makes use of lots of services, and an api is just a service.
Many developers have the initial gut reaction to build instead of buy. I've found that many people don't really fully understand the ramifications though. Even if some of these places only have 3-5 developers working on this full time - that's still probably FAR more resources than another company, especially a startup, can devote to the problem. You also now need resources to maintain and update it. All of this takes resources away from whatever it is your business actually does.
I guess the hard part is really determining what is trivial vs what is worth letting someone else take over. Some people may look at the above services and feel like they look pretty easy - and then a week or a month down the line they realize there is more to it than they first thought.
Other aspects people often don't think about - dashboards and admin sections usable by a non-developer.
I'm not vouching for any of these services as I have never needed to use any of them, but I would definitely guard against blind "not invented here" syndrome.
Why would you duplicate what other people have built before you? Everything that has been done correctly by others, you should use. Learning how to configure Asterisk and how to use Twilio doesn't nearly require the same amount of time.
I agree to some extent that you should not rely on other services without having any kind of replacement, but to say that you have to build everything yourself seems rather ill-informed advice...
Given the choice between spending a day or a weekend building something in house, or using a remote web service, I will always bring it in house. Because it's ridiculous to rely on some remote service if you don't have to.
If it will take me a couple of months to replicate something which already exists as a web service, I will usually use the web service. If only temporarily.
None of the web services mentioned so far on this page seem significantly difficult to replace, and suggesting that people use them seems rather ill-informed advice...
I think it matters whether your business has found product/market fit. Before product/market fit, taking the time to build things in house increases risk--risk that you're wasting your time on a product no one wants. After product/market fit, it reduces risk--risk that your product that people are paying for will have reliability problems.
I wrote this article. I think it's more accurate to say "Building software on top of someone else's web api can be a really, really bad idea" -- if you don't do due diligence. I've written about the perils of building on top of consumer web platforms in the past, and personally think there's far more risk in building apps for, say, Facebook and Twitter, than incorporating into your own product a commercial API that you've vetted reasonably well.
Developers/entrepreneurs need to be pragmatic. New ventures that spend all their time and money trying to eliminate risk usually fail; the ones that succeed instead try to manage it. When working to get something to market to see if it will fly, it can be a huge mistake to invest in building low-level functionality from scratch. Most developers/entrepreneurs, for instance, aren't going to build their own video encoding engine. Sure you could use ffmpeg, but out of the box ffmpeg is hardly Zencoder. The time, cost and functionality advantages of Zencoder certainly outweigh whatever risk there is that Zencoder would go out of business in the near term.
In short, it's about cost and time-to-market. Reinventing the wheel usually increases both. So unless you have unlimited resources and already have a strong presence in a market, it's far better to bring a lot of this stuff in-house after you've validated that there's a market for your product and it's making some money.
Cloudmailin is exactly what I was looking for the other day. Perfect way for me to write a simple Tropo app that calls (not texts) me when a server fails and leaves me a voicemail with the error. Oh and add https://www.tropo.com/ to your list.
I could do what cloudmailin does with ~6 lines of Perl and a procmail recipe...
Uploadjuicer can be replaced with imagemagick. Should be less than a days work to write a web service if you really need one. Host on AWS and bring up more nodes if you need to process more images than one node can handle.
Recurly looks like it offers real value. I would use Recurly, but with the intention of replacing it with my own custom system after a while.
Pusherapp - Trivial to replicate in house. Their front page also refers to browsers which don't support WebSockets as "crap"