If you want to learn more about the real story behind mashups, APIs and tools — the good, bad and the ugly — you’re in luck. Today we’re introducing a new feature on the site: the ProgrammableWeb Case Studies. In this ongoing series we’ll be going behind the scenes of the programmable web by talking with mashup developers, API providers, tool vendors, and other notable players in this ecosystem.
Over time this collected knowledgebase of experience can hopefully help us all get a better understanding of who’s doing what, what’s working, what are the viable business models, what are the technology tips-and-tricks, and finally, we might pick-up some good anecdotes along the way.
Our first interview is with Matt Douglas, CEO of MyPunchbowl, a Boston-based startup focused on event and party planning. As part of their service they integrate a variety of third-party APIs for things ranging from mapping to contacts to media management.
1. What is MyPunchbowl and why did you start the company?
MyPunchbowl.com is a new web application for event and party planning. It features an easy to use interface and tools for every step in the lifecycle of a party. We built MyPunchbowl because we didn’t like the current products on the market, and we had a vision for a product that would help a user with every step of party planning. Fundamentally, we built the product for us. And we hope our customers love it too.
2. What APIs did you use and what were the best and the worst aspects of using them?
3. What programming languages and tools is this built with?
MyPunchbowl.com is a Ruby on Rails application. The site is built on Prototype/Script.aculo.us, with a MySQL database. I’d be remiss if I didn’t also mention our awesome bug tracking system– we use a product called Squish that serves our needs very well.
4. What is your business model?
MyPunchbowl.com has a large revenue opportunity. Our business is based on a number of different revenue sources including targeted advertising, revenue sharing on supplies and merchandise, and affiliate revenue through booking partners. In addition, we believe our core software is an attractive package to license to key brands in the event and party industry.
5. Can you tell us about any metrics for this application: traffic, revenue or other?
We’ve had a very successful launch thanks to mentions on such great sites as ProgrammableWeb. For us, the key has been an aggressive PR strategy, that has paid dividends in traffic and users.
6. What are the near-term and longer-term plans for this project?
We’re working on making MyPunchbowl.com the best event and party planning application on the web. We’re fortunate that we have very vocal and passionate users. They’ve been very clear about which features are the most important. In the long-term, we think we have some unique ideas which will change the way people plan parties. We also have some creative ideas about how to make the product more collaborative. Look for us to also find unique channels and strategic partners as we grow the business.
7. Do you foresee using other APIs as part of your service in the future?
Oh yes, definitely. We think using API’s has a couple of distinct advantages. First, it helps us accelerate our product development. Second, users like the ability to leverage their content. For example, the Plaxo Address Book widget is an example of a feature which allows users to quickly import their address book into MyPunchbowl. We don’t have an address book feature in MyPunchbowl, because we personally don’t like having to maintain more than one address book. Using the Plaxo API gives us the ability to bring the content of an address book in easily, regardless of where you maintain your addresses.
8. Using third-party APIs is seen by many as introducing business and technology risk. How do view this issue and how do you account for it in your strategy and implementation?
This is something we’ve talked about a lot, and the good news is that there are new libraries coming out that allow you to “cascade” API’s. For example, we use Yahoo geocoding, but what if Yahoo goes down? We think the best thing to do is to implement a library that will immediately go to Google geocoding (or any of the others) if the one fails. We think this is a great way to mitigate our risk and there are lots of great libraries for Ruby on Rails to do these kinds of things like the plug-in for Rails called “acts_as_geocodable”.
9. From an API and mashup perspective, what are the main lessons learned from this project and/or is there any advice you’d like to share on the development, design or business side of mashups?
The key is to test, test, test. For us, we have spent a lot of time making sure that our implementation is bullet-proof in all of the various browsers. We’ve had lots of stumbling blocks along the way– for example, Google maps are pretty finicky in IE. We think it is important to treat the API features as if they were our own. After all, our customers are the ones who are interacting with the functionality. Test, test, test. And when you are done, test some more.
10. Are there any mashup-related APIs, tools or services that don’t exist today that you’d like to see? (Or, what API would you kill for?)
We really wish that there were some more standards out there for API’s. For example, wouldn’t it be great if there were a standard creative commons API for all images on the web? That way, we could do a single search rather than pulling from all of the various photo sharing sites. As video grows online, this is going to be an issue too. Right now, we integrate with YouTube, but there are many others out there. API’s are great, but it does take significant resources when we have to implement the API for one service at a time.
And finally, besides your own, do you have a favorite mashup?
Big thanks to Matt Douglas for helping us kick-off this series. More to come.