Mashup Case Study: MyPunchbowl

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? 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? We use a handful of API's right now including Google Maps, Flickr, YouTube, and the Plaxo Address Book Widget. We've had a lot of success extending our product by utilizing these API's. What we've found, however, is a significant difference in dealing with the companies behind these API's. Plaxo was great; they were responsive to our needs, and their support forum is very useful. Some of the other companies weren't as helpful. In one case, we had a question about terms of use, and it took a lot longer than you would think (weeks!) to get a clear answer. We plan to continue to expand our product through the use of API's. For a startup like ours, it's a great way to implement a lot of functionality in a short amount of time. 3. What programming languages and tools is this built with? is a Ruby on Rails application. The site is built on Prototype/, 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? 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 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? I'm still partial to HousingMaps, because I remember that when I saw it I had the distinct feeling that I was looking into the future. And Goggles is always fun. Big thanks to Matt Douglas for helping us kick-off this series. More to come.

Be sure to read the next Best Practices article: eBay Tops Web 2.0 Developer Survey


Comments (6)

The case study idea is great, but the information density in this particular article is low. There is too much sales talk about MyPunchbowl and the information presented about the company's business model is extremely vague. I'd like to read specific war stories. And the article should cite details, for example, which vendors' APIs were hard to use, what exact questions took a long time to answer, and why. Still, this is a very good start.

[...] to John and Programmableweb for a engaging interview and a great site. Check out the MyPunchbowl interview with Programmableweb. Share and Enjoy: These icons link to social bookmarking sites where readers can share and [...]

Thank you for the awesome post, nice site to! It makes be want to improve my blog. What software do you need to get started? I hear a lot about this Blog Engine?! Bondara

<strong>San Antonio Web Designer...</strong>

Nice information you have here ill be sure to pass this along to some of my friends and bookmark your site. Ill check back often....

[...] Thanks to John and Programmableweb for a engaging interview and a great site. Check out the MyPunchbowl interview with Programmableweb. [...]

Werner, thanks for the feedback. Indeed we'll keep working on the case studies, getting into more specifics and and over time I suspect we'll refine the questions as we learn more from previous cases.