[lmz]

> most of them should be able to build their own service.

Isn't the hard prt the connectivity bit i.e. negotiating with the various telcos? I once saw a telco use a third party SMS vendor for messaging their own customers for an app - because setting it up internally was too much of a hassle.

[stavros]

No, the hard part is having to secure all these little random services that I've now built. Why would I not just pay for someone whose job it was to worry about this instead?

[PinguTS]

So you say, that for Google, Amazon, Facebook, Microsoft, which are among those costumers, it is too hard to negotiate with the various teclos?

[lmz]

Not in the US at least for those companies, but the world is a big place and this other comment https://news.ycombinator.com/item?id=40935323 mentioned places like Gambia and Burkina Faso... It just makes sense to outsource local delivery to companies that are better connected locally.

[Tepix]

It's not their core business, which is why they let SMS aggregators deal with it and merely switch inbetween those.

[fatnoah]

Yes, and there are multiple levels of aggregators. For example, in a past life, I built SMS APIs and back-ends, including ones used by smaller telecoms to enable their subscribers to send/receive SMS. (We were pretty small, and only accounted for something like 0.5% if US SMS traffic)

We connected to multiple aggregators. It's been a few years, but the big players in the US (Verizon, AT&T, Sprint, T-Mobile) were split between different aggregators. It was a similar situation in Europe.

A big part of working with a new aggregator was a full review of security and privacy, and that became even more important as we began the process of being acquired by an F100 company.

I'm still trying to figure out why messages were stored in S3 buckets to begin with. That's an architecture choice that makes little sense to me, especially since the limited size of SMS makes them pretty space efficient.