Seattle Startup Buzzeromatic Makes Doorbells Smarter Using Twilio

September 27, 2009
Written by
Danielle Morrill
Contributor
Opinions expressed by Twilio contributors are their own

Twilio Bug Logo

Buzzeromatic

As you may have read in ReadWriteWeb‘s ReadWriteStart channel, Buzzeromatic is a Seattle startup that is simplifying the way apartment residents manage the people who have permission to enter their building.

The simple idea behind the service is that since you control the buzzer to your front door with a phone, Twilio can be used to make that interaction a whole lot more sophisticated.

Whether via the web interface, or through SMS commands, users can:

  • admit people to the building
  • create passwords for regular guests
  • receive voice messages from delivery staff

Great news – according to the Buzzeromatic team there is also an iPhone application coming soon!

O Brave New World – Making Voice Accessible to Developers

We’ve been beating the drum about how important it is to provide simple tools with straightforward pricing and functionality, so that developers can take tasks like telephony programming and make them easy, so it’s great to hear that the existence of Twilio was crucial to the inception of Buzzeromatic.

As Jolie O’Dell reports:

Co-founder Andres Krogh told us that he and a friend bootstrapped their
startup. “The only reason we’re able to pull it off is because of the
explosion of commodity VoIP APIs like Twilio lately that make it
somewhat cost effective.”

Buzzeromatic Co-Founder Andres Krogh Weighs In on Twilio

We had a chance to ask Andres about building Buzzeromatic as well as his experience developing with the Twilio API, and here’s what he had to say:

What gave you the idea to create Buzzeromatic?

The idea had been percolating for awhile – I had a house guest that needed to crash on the couch a few months ago, and since they weren’t residents I couldn’t get them a swipe keycard for the building.  They’d have to buzz in as they came and went, and a lot of times they ended up out in the cold because I was working out of a coffeeshop with bad reception, or was in the grocery store with bad reception, or just missed the call entirely.  A month or two later Matt ended up having the same problem at a football game at a friend’s house, where the guests kept getting locked out when the guy that lived there wasn’t near his phone.  He was over one day and I mentioned that I had rigged my buzzer with Twilio to see if it’d work, and he grinned like we just discovered electricity.  The rest is history….all two weeks of it since then :)

What technologies (APIs, languages, etc.) did you use to create the service?

Twilio’s api’s are the bedrock for the whole operation, without a doubt. Past that, most of our stack is C# and MS SQL – I’m a .net guy, for better and worse, so that was our immediate pick-up-your-compiler-and-go reaction when we started proof of concepting it.  My first love will always be actionscript and flash though, so I managed to shamelessly shim Flash into the Buzzeromatic ux (and Twilio interaction) wherever possible.  We have a few places where Flash dynamically loads and plays a voicemail recording from the Twilio api, etc, and it works like a charm.  The great thing about using Twilio’s api was that they make it easy to bring your own backend stack to the table, whatever that may be – even if it happens to be something as esoteric and front-endy as Flash.  We’ve had to integrate a handful of api’s to bring Buzzeromatic together, and by far Twilio’s was the most pleasant to deal with.  Try integrating a payment gateway sometime – ‘nightmare’ doesn’t begin to describe it.  You assume that telephony will be just as ugly, but it’s a fluffy cakewalk on the Twilio stack.

Can you tell us anything about the Twilio implementation?  How long did it take?  What were some challenges, surprises?

We’re still putting finishing touches on the app, but all told it’s just been a few weekend’s worth of work.  Getting rolling was quick, but the core Buzzeromatic engine that drives your buzzer has actually gotten surprisingly sophisticated.  You get to tackle some unusual hurdles when building on top of a restful api – especially having personally come from the gauntlet of past ill-fated Microsoft webservice stacks like Soap.  Usually managing state (and doing it securely) is a beast of a problem when you’ve got this kind of deep interaction with someone else on your backend, but even that’s been thought through in the Twilio api, with cookie support, etc.  It was one of those hack sessions you always want to have, where it was never about what we couldn’t do.  It was always about what we could do.  And how late the coffee shop was going to be open.

If you had all the time in the world, what would you build with Twilio?

Probably Buzzer – the idea’s been couped up for quite some time now, so it’s nice to let it run wild.  But beyond that, I’ve been intruiged with some of the more humanitarian-esque projects getting baked on top of Twilio recently – I liked the H1N1 hotline idea, and the integration the National September 11th Memorial & Museum guys did.

The gratuitous artist in me wishes someone would build a ‘Just called to say I love you’ site, just a single page with a pretty-yet-minimal flash ui, and a big ‘call me and let me record a love note for someone’ button, and then email the recipient for playback whenever they can get to it.  For families that are in different parts of the world due to work or war or whatever.  Sometimes just hearing someone’s voice can mean everything.  Especially when you don’t have a phone handy.  But that’s just my sappy art background getting the best of me – I’ll buy coffee and a muffin for the first gratuitous artist to go build that.

Anything else you’d like to share with us?

I heart Twilio.  And the api. We’ll (theoretically) be launching the closed beta in the next week or two sometime, and working the kinks out of the system.  This is the tip of the iceberg, though – the features we’re building out currently are the things we decided the service absolutely couldn’t live without, but for every one of these features we’ve got 10 more we thought of on top of Twilio that we had to (heartbreakingly) shelve for the future.  All in good time though.

Have you launched a company, product, or feature that uses Twilio?  We’d love to hear about it and share your experience with other Twilio developers.  Drop us a line at help@twilio.com anytime and we’ll share your story here on our blog.  Happy coding!