Subtitle: “When you are betting your ass on a platform, if you have a choice of platforms, bet on the company that *has *to deliver an actual working solution to survive, not on a company for whom the platform is an interesting diversion from their core business.”
I like the folks at Voxeo a lot. But I had to shut down an earlier business because their business model of paying per-port per-year is unworkable for a business with significant peaks and valleys in usage. (The business was a voice message broadcast system for schools, etc., where virtually all of the user activity happens within fairly narrow time frames. But after a short eval period we had to pay for ports 24x7x365 even though our customers’ usage occurred during perhaps 10% of a typical week. And since users expect messages to go out in a timely way, simply having 1/10 as many available channels was not an option.)
So I was very excited a year or two later when they introduced Tropo, cloud based telecom with no per-port fees, pure pay-for-use business model. even though it was too late for the prior business.
When a new project that required voice and SMS came along, I thought Tropo would be perfect. But Twilio looked interesting as well. We built a fairly significant app that handles inbound and outbound voice calls and SMS, and looking at the claimed features, Tropo looked like a hands down winner. Nonetheless, we architected the product to be relatively platform neutral “just in case.”
Once again, my belt-and-suspenders approach to app architecture paid off because Tropo was a lot of cool things, but “ready for prime time” is not among them.
Going into the project, here’s what initially convinced us to incorporate the Tropo platform:
Supposed advantages of using Tropo over Twilio:
- Tropo is based on Voxeo, a mature and highly profitable company/technology, Twilio is a startup
- Tropo has voice recognition, Twilio doesn’t
- Tropo apps can (supposedly) send/receive tweets via an associated Twitter account, allowing you to (supposedly) build very cool automated Twitter apps. Twilio doesn’t. In fact, when you go to tropo.com their headline reads “Add Voice, SMS, Twitter, and IM to Your Applications”
- Tropo has 24×7 tech support, Twilio doesn’t.
- Tropo is (supposedly) more robust, built as it is upon the Voxeo platform.
- Tropo has a very generous “free for development” policy so you can get up and running without paying for phone numbers and messages.
We dabbled with both at first, to get our feet wet, then proceed to build our app on Tropo. Addressing each of those (supposed) Tropo advantages in order, here’s why we were absolutely compelled to switch to Twilio.
- The overall impression I got was that Tropo being a disruptive pay-for-use business model offered by hugely successful company is that, well, they’re just dabbling with this… that Voxeo has no current profit motive to make it work right… their mainline business is (a) doing just fine thank you and (b) might even be disrupted if Tropo works *too *well. That’s just my impression, but it’s based on the following:
- Voice recognition. This claim is actually true, although Tropo does not offer (built-in) the full range of VXML grammars that make voice recognition practical. And we found that ambient noise makes it unusable for Real World Apps if your users are commonly on cells, in restaurants, or cars.
- Twitter. UPDATE: This seems to have been fixed recently. So far so good.
In my experience, attaching a Twitter account to Tropo app works for maybe one day. Then the connection to Twitter silently dies, and there is NO way to tell it’s happened. YouR app just stops receiving tweets. There is no API to verify or restore the connection. You have to remove the Twitter account, then re-add it, manually. But remember… you have no idea when your Tropo/Twitter connection is broken. We tested several Tropo apps, with several Twitter accounts, over several weeks and the results were absolutely repeatable… Tropo apps fail to respond to Tweets within a day or two. It just plain doesn’t work. And it’s not Twitter’s fault… another thing we tested was whether an app like Hootsuite would ‘keep’ it’s connection to Twitter persistently and during the same several weeks of testing, had zero problems with Hootsuite. Now, I’m all about ‘things will get better over time’ except… well… when the company’s *headline *says it works… it kinda needs to work.
- *Tech support. *Actually this was a tie. We’d send support requests at midnight and get a prompt “I’ll have someone look at this” reply from a human at Tropo, but the actual answers came faster from Twilio about half the time. And on some major issues (Twitter, ‘lost’ SMS messages) it took Tropo a week, even two to respond, whereas we never waited longer than a working day from Twilio.
- In our experience, Twilio is more robust, period. Let me count the ways: - UPDATE: this ‘feature’ was finally removed so they no longer opt-out your users for you.
If your user texts the word STOP to your Tropo app, your app does not get to handle the opt-out… Tropo does it automatically, and silently throws away all traffic to that user. Your app never knows about it (neither does the user!), and for all you know your messages are going through. This is wrong. A telecom platform should *not *silently throw away messages. (Twilio doesn’t presume to opt-out your customers, they let your app do it so you can keep track of it!)
- Tropo silently fails to deliver SMS messages if your app sends them too fast. And there’s no specific rate, just general guidelines of ten per minute. Twilio lets your blast them out as fast as it wants, then Twilio handles the rate limiting to 1 per second. In other words, Twilio is designed for reliable message delivery, Tropo is “best efforts” and (even worse) does *not *inform your app when something went wrong.
- To simulate modest concurrent user loads, we wrote a two very simple tester apps: one app sends 10 SMS messages to another app. We never, not once, got all 10 SMSs to make it on Tropo. Twilio never missed a message. Tropo support said that’s strictly an artifact of apps-talking-to-apps related to their gateway, that it would not happen if multiple cell phone users were talking to, but…. would you bet your ass on that? (Me neither.)
- Tropo doesn’t have the very helpful callbacks Twilio offers that let you do post-sessions.
- There’s five more items on my list, but candidly, IMO the issues of Tropo discarding or losing messages, silently, under multiple circumstances, should be enough to cross them off any developer’s list.
- Free vs pay-for-use during development. Tropo is free. Twilio isn’t. At Twilio a phone number costs $1/month at Twilio. Text messages or phone-minutes are 2 or 3 cents each. Dude, if you’re building a business do you even *care *about $20 to $40 in telecom charges during a month of testing? (Me neither.) What you do care about is building something that works reliably when your users use it.
So that’s why we are deploying based on Twilio, not Tropo. (Though we left our Tropo code in place for when they get it together on the message-delivery-reliability front, and get Twitter working, we’d love to use that feature.)
But the moral of the story is clear to me: if your providers aren’t betting their asses on doing a great job for you, you may not want to bet your ass on their services. Ditto hosting, web design, you name it.