Of course I agree with the idea that integrating with an API can make your software more fragile (it's a truism), but you greatly understate the costs of Not Invented Here syndrome.

To a few of your points:

- Twilio - Spend the time you'd use learning Twilio to learn how to configure up Asterisk instead. Set it up with multiple SIP providers with multiple PSTN gateways.

Seriously? The idea that going from zero to production on Asterisk takes roughly the same time as doing it with Twilio is risible.

- SimpleGeo - No need to use a web service for this. You can get IP to geo data for free nowadays, and every programming language has a library for it.

Again, preposterous. That's not what SimpleGeo does, even the briefest look at the homepage shows that: http://simplegeo.com/

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.

>Given the choice between spending a day or a weekend building something in house

Remember that building it is not the only cost; you also have to consider the costs of maintaining it and keeping the servers running.