Hacker News new | past | comments | ask | show | jobs | submit login
Twilio Raises $12 Million For Powerful Telephony API (techcrunch.com)
63 points by gspyrou on Nov 9, 2010 | hide | past | favorite | 35 comments



I was an early Twilio user and love the service (and them - some great guys there) but added to their existing ~$4m of funding, that's $16m of funding investors are expecting to get back (with a generous profit on top) sometime.

Can something like Twilio really become a $100m+ company? I hope so but my ignorance blinkers me to how this could happen..


Why not? Companies make billions upon billions of dollars every year selling voice service to businesses. Asterisk is still too complicated for most businesses, I have to imagine there is a huge market for easy to use voice apps.

They may not end up selling directly to small businesses, but power things like patio11's reminder service that then in turn are sold to the mom and pops of the world. OpenVBX looks pretty neat too, it's crazy how much businesses usually pay for this sort of thing.


I think Twilio is going to get a few hundred or thousand dollars from me next year (please God, let it be a few thousand). That will pale in comparison to the revenues if they attract a few Fortune 500s to do big critical line-of-business apps through Twilio. (Think like e.g. automated flight status for Delta.)

Thomas and I were talking about this the other day. A lot of potential Twilio apps replace offline processes. Let me repeat that for emphasis: replace offline processes. That puts the potential cost savings at "ginormous".


Good point - that's exactly the type of answer I was hoping to get. I guess I forgot the value in being close to the metal. Twilio's customers aren't necessarily end customers but companies who, themselves, are attempting to make serious money from Twilio's products and will be forking over huge amounts of cash on a regular basis ;-)


Evidence for this can be seen in their volume pricing discounts:

http://www.twilio.com/pricing-signup/volume-pricing

I doubt many single customers will require multiple thousands of phone numbers or be using more than 15 million minutes a month (that's 1,500 people on the phone for 8 hours every week day of the month).

OpenVBX is somewhat a direct-to-business play, but they stayed out of the pool by open sourcing it and then by hinting that others are allowed to re-sell it (more minutes for them!). It's really slick though:

http://www.twilio.com/openvbx

I could see a Big Telco scoop them up for tons of money in the near future. All those cushy business lines are going away at a rapid pace, they need to get in on the next big thing. The players are huge, a $100 million buyout would barely even make the company newsletter (case in point, AT&T banked $12.5B last year).


Telephony is one of those markets (like health care and education) that is valued over $1 trillion on a global basis -- turning Twilio into a $100M company seems totally plausible.


I think any company with 20,000 developers who spend money on its platform is worth (arbitrarily) 100M.


They do give a free trial, so I'm not sure if all 20,000 are paying customers. Still, they are doing a fantastic job reaching out to the developer community.


The telecom market is certainly big enough and 100m should not be such a big problem. As such a lot of new uses of telephone are being identified and we have been seeing them even in our platform KooKoo. You can find more of my thoughts at http://cloudtelephony.blogspot.com/2010/11/phone-use-cases-d...


Ribbit, the first Telco API that I know of, was sold to BT for 105 million if i'm not mistaken. So....I could see that happening again.


But unlike Ribbit, Twilio has traction and a business model.


True. I didn't really understand the Ribbit purchase myself, but my point was, the sky is quite high for telco companies.


Twilio Labs has some really neat stuff: phone calls and SMS from the command line. You can give it an mp3 file and it will play it for a list of recipients.

http://labs.twilio.com/bash/index

http://labs.twilio.com/bash/sms


I hope they invest a lot of that in innovating and not just marketing/scaling. They've had a decent pace so far but there are still some large holes to fill. I'd like to see:

* Conferences that support more than 10 people.

* Flash RTMP streaming (even just for outbound)

* SIP support

There's a lot of cool business stuff that is almost within reach of twilio. Keep innovating guys.


Thanks for the feedback. We definitely want to keep innovating and we're working hard to improve as much as we can!


Conferencing is very challenging for more than ten people.

When you say SIP support, what do you mean?


Session Initiation Protocol: http://en.wikipedia.org/wiki/Session_Initiation_Protocol

SIP is the IETF's answer to the ITU's H.323. It's very similar in design to HTTP and most major enterprise telephony infrastructure providers have been migrating to it at some non-trivial pace. Of course, the big problem with SIP is your SIP and my SIP aren't always the same. This is becoming less of a problem as more folks deploy it, but if you look at how Cisco bastadized the SIP implementation on the line side of their IP PBX, you'll know what I mean: lots of proprietary extensions to make the various line-side features working.


Heh. I know what SIP is. I've done a lot of telco programming. What I meant was, in what way do you want twilio to support sip? I'm sure it's what they're using on the backend, with a sip trunking provider (or multiple)...

Is there a reason to want them to send SIP rather than calls over the PSTN? If you want SIP, using a hosted solution may not be the answer...


Large scale conferencing may be challenging but it's also pretty expensive and an attractive service to take a slice of. We currently use a service from our telco and have run up to about 40 people for our training sessions. So it's definitely doable.

You can't have more than a few talking at once or it becomes very unwieldy. Is that what makes it hard? Having to multiplex 40 input channels together? Would it be easier if most of the lines were muted? Because that is a workable compromise.

As for SIP support, it potentially opens up twilio service to some neat applications were one end of the phone connection could be hosting in a web app via flash/silverlight.


>You can't have more than a few talking at once or it becomes very unwieldy. Is that what makes it hard? Having to multiplex 40 input channels together? Would it be easier if most of the lines were muted? Because that is a workable compromise.

Oh. Yeah, I'm not sure that's even considered conferencing in the telco world. No mixing involved if that's the case, just transmitting multiple streams.

The hard part is mixing that many people without having background noise, etc. make everything inaudible.

>As for SIP support, it potentially opens up twilio service to some neat applications were one end of the phone connection could be hosting in a web app via flash/silverlight.

Ah, I see.


>> one end of the phone connection could be hosting in a web app via flash/silverlight.

Have you seen Phono? http://phono.com/ - It does exactly what you're describing. Phone in the browser, talking to a SIP backend.


Interesting. Chris Matthieu gave a rockin' demo of Voxeo's PhonoSDK, a jQuery plug-in that makes building SIP-enabled Web pages stupid easy. Looks like there are some really interesting players in the phone space.


More than a few. Ribbit is the big one, but not getting too much press these days. Voxeo is for IVRs, but Tropo.com is owned by Voxeo and has a very twilio-ish API.

There are a few more smaller players.

And then there's the stealth project I'm working on with some people. Going to be quite disruptive...


I initially liked Twilio but I actually went with Tropo for a small project as the ability to upload a Ruby script kept everything easy. No need to learn another language or even use a RESTful api. Just write the script, upload and you're good to go.


I believe Twilio has wrappers around their REST API in various languages, so you don't have to deal with any of the web stuff.

However, you'd still have to host your own scripts, so if Tropo does your script hosting, there's that advantage. How do you communicate with the rest of your App though? Or does it exist entirely on the Tropo 'cloud'?

Care to share what the app is if it's a public thing?


Sure: http://github.com/hopeless/phone2post (ring a number to record a podcast and publish that to Posterous)

yeah, Tropo hosts the scripts for you so it meant that all the telephony stuff is handled by tropo.rb (on their servers) and this posts the mp3 to my sinatra app (phone2post.rb), which can limit itself to acting as a proxy for Posterous. I prefer the separation of concerns that this permitted me. For a more complicated app, I can definitely see the advantages of controlling the telephony side from the web app but in this case it wasn't necessary.


I built a Twilio Ruby gem for a project, after not being happy with the official library (poor code quality and poor test coverage)

http://github.com/stevegraham/twilio-rb


We're working on all new libraries that will be MUCH better than the ones we have now. Should be out soon.


Do you plan to re-enable SMS delivery outside the US ?


Hi gspyrou... yes, we'll do it and be able to fully support it like we do with our US SMS.


Glad to hear that , because at the moment this is a show stopper for our project.


Thank you!


I hope this means they're expanding to support more countries fully(number provisioning and sms). Especially Australia.


Hi audeyisaacs, international capabilities are very high on our priority list... we're listening :)


Awesome!




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

Search: