Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That's a superb article re: real-world Twilio. We did a head to-head with twilio and tropo and twilio won hands down in terms of actual "production-worthiness" despite tropo having "more" features including speech reco. http://pardner.com/2011/04/tropo-not-ready-for-prime-time-we...


> We did a head to-head with twilio and tropo and twilio won hands down in terms of actual "production-worthiness" despite tropo having "more" features including speech reco.

Had the same head-to-head, and Tropo won for us. Tropo has substandard docs and higher prices, but the tech and API is top notch. We also needed the international coverage. Regardless, they are both great products and great companies. You can't go wrong with either, unless you have very particular needs.


Don't disagree. Tropo does some extremely cool stuff... having a single app handle IM, SMS, tweets, voice is kinda magical. Seems to have better local number availability as well. The lack of any rate limiting handshaking for handling sms blasts was a deal killer for my app however... imo if you try to push sms faster that they can send it they should either queue the messages (as twilio does) or provide handshaking that says "can't send that message" instead of silently discarding the message.

That said, our app uses a mashup of both tropo and twilio now, we use tropo to handle "tweet" dialog with consumers.


> imo if you try to push sms faster that they can send it they should either queue the messages (as twilio does)

Absolutely! I simply don't understand that decision. I mean, I can create my own internal queue to get around the problem, but that burden shouldn't be on me.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: