November 1st, 2007

Mashup Case Study: Nestoria

In this installment of our mashup case study series we speak with Ed Freyfogle, the founder of Nestoria, a property search engine in the UK and Spain. Their service makes extensive use of the Google Maps API and other sources to include richer information about properties and neighborhoods. They are also an example of an “API stack” since they build on top of APIs but also provide an API of their own.

Q: Can you give us a bit of background on Nestoria?

We’re a vertical search engine for the property (real estate as they say in the US) market. We operate in the the UK and Spain. We focus on helping people find exactly the home they want to buy or rent as quickly as possible.

We’re a small team and very technology/data/engineering driven. We have several internet veterans with a background in in websearch (Yahoo), ecommerce (Amazon) and paid advertising (Overture).

Q: What is your business model?

We believe strongly in performance based marketing. Right now that takes the form of pay per click, but could in the future be pay per action.

Q: What APIs did you use and what were the best and the worst aspects of using them?

Users love our integration with Google Maps, and we were used by Google as a case study for their API.

We access the maps via Mapstraction, something I recommend to anyone building a mapping application. It creates an abstraction layer across a variety of mapping APIs.

We mashup all sorts of local data that people might find relevant about a local area. This includes government data from TheyWorkForYou, photos from Panoramio, points of interest from Tagzania and parking data from ParkAtMyHouse.

We’ve also done projects with OpenStreetMap and relied on data from Geonames and New Popular Edition Maps.

We also provide access to our entire database via our own API and provide GeoRSS feeds, widgets and co-branding tools for people to use our results on their site. We also have Facebook applications for both Spain and the UK (we built the first non-English language Facebook app).

Q: What programming languages and tools is this built with?

Our entire site is LAMP - Linux, Apache, MySql, Perl. We chose perl for CPAN which helps us move much faster.

Technically the piece of Nestoria that I think is most interesting is sadly the piece we can’t really show off; We’ve built a very extensive metrics and testing system that allows us to continually monitor and tweak site performance.

Other than that we’re always on the lookout for useful tools to help us. A good example is YSlow that Yahoo! recently released. We were happy to see we scored a 94 out of 100.

Q: Can you tell us about any metrics for this application: traffic, revenue or other?

For the UK, Comscore reported us with 178,000 unique users and in June 114,000. Spain we just launched in mid-May, but Comscore says we had 39,000 in June.

Q: 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?

To be honest, we worry about this less and less, as more businesses see the benefits of opening their data and tools. Nevertheless, it is something to be aware of. This is exactly why we sponsored the development of Mapstraction to make it as easy as possible to switch to another mapping service if we were ever forced to switch.

Q: 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?

A lot of people are tempted by the technical ease of whipping up a mashup. Building a website and building a sustainable business are two very different things. My advice is to do some real thinking about the value your service provides.

Q: 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?)

A working international rss-to-email service and working versions of the TheyWorkForYou API for other countries.

Q: And finally, besides your own service, do you have a favorite mashup?

Here in the UK I think ParkAtMyHouse is a brilliant idea.

A big thanks to Ed for joining us in our case study series.

Share This

Posted by John Musser as CaseStudies, Mapping at 2:52 AM | 2 Comments »

October 8th, 2007

Using APIs for Charity, Part 2

In this second and final installment of our mashup case study on Giveness, we pick-up from Part 1 and our conversation with founder Richard Waldvogel by digging into more details on REST vs. SOAP, caching and other mashup lessons learned.

Q: Do you find the Amazon or the ebay API easier to work with?

Getting our eBay API account set up required more attention than with Amazon. You have to store a DevId, AppId, CertId and tokens for REST and SOAP to authenticate your requests. A unique set of these are required for Sandbox and Production communication. Once you save these values to a config file, your done, but it’s a little bit more work up front comparatively.

Read the rest of “Using APIs for Charity, Part 2″ »

Share This

Posted by John Musser as CaseStudies, Featured at 1:24 AM | 2 Comments »

October 4th, 2007

Mashup Case Study: Giveness

How can open APIs be used to help charitable causes? In this case study interview we speak with Richard Waldvogel, founder of Giveness, a social network for philanthropy that builds on open APIs like Amazon’s and eBay’s to enable people to support their favorite charities while they shop.

Q: Can you give us a bit of background on Giveness?

A: The concept behind Giveness started in late 2003. At that time I was thrust into a scenario where I was doing a lot of fundraising. When a good friend’s life is on the line, it really hits home, you get slapped with a reality check and your perception of fundraising changes. I discovered that fundraising can be an extremely time consuming and stressful task and as a programmer, I started to think of ways that I could solve the bottlenecks in the system.

Having just finished a large project that used the Amazon AWS service extensively it dawned on me that instead of asking all of my coworkers for a $5 dollar donation, I could simply ask them to make their Amazon purchases through a service that funneled those Associate commissions to a charity. Myself and Dan Werling launched Givezilla.com in 2004. In mid 2006, we started working on our next version of Givezilla.com and launched Giveness.com in March 2007.

Q: What is your business model?

A: Our main vision is provide a service that allows a supporter to make a purchase from a merchant affiliated with Giveness and allow them to personally designate which charity will receive the commissions generated from the sale. Each network benefits from this connection. Supporters are given the opportunity to easily generate additional funds for a cause they have an interest in without incurring any additional out of pocket expenses. Charities can leverage a new revenue stream that is easy for them to complement their existing fundraising programs. Merchant networks get another service promoting their products and generating more sales.

Currently, our revenue comes from advertising. Sponsorships and premium services are also revenue channels that we are pursuing. We are adamant on ensuring that 100% of the commissions generated from the supporter network go directly to the supporter’s selected charity at Giveness.

Q: What APIs did you use and what were the best and worst aspects of using them?

A: We use a variety of APIs from several different companies. Currently we use Amazon’s ECS for shopping and their S3 service for storing all our media. To broaden our user’s shopping options, we implemented eBay’s API for auctions. To fill out some of our offerings, we also work with Google’s Map API and geo-coding services along with their video service, as well as YouTube’s.

The best and worst aspect of working with Amazon’s and eBay’s commerce services is their sheer size. It’s important to use the services that support your overall goal and not incorporate every feature that is available.

Standards become an issue when you’re trying to incorporate different APIs that cover similar services. You really have to study the schema to understand them in a way that allows you to incorporate each service into your object model. One service may call the name of a product “Title” while another refers to it as “Name”. I don’t foresee this issue going away anytime soon.

The more mature APIs are really starting to stabilize, but if you are intent on working with some of the newer ones being released, then you better be prepared to make changes in your code on a moments notice.

Q: What programming languages and tools is this built with?

A: We use C# on top of the .NET framework for our main development. We utilize REST requests for our API communication. SOAP is easier but the REST method saves us from having to manage numerous and potentially bulky .wsdl files in our projects.

Q: Do you foresee using other APIs as part of your service in the future?

A: As our community grows, we’re looking to integrate communication tools that allow our users to connect with one another through Giveness. We think there are some interesting opportunities with a service like the Skype API where someone seeking help or counseling could speak with other members that are experiencing the same issues.

APIs don’t necessarily need to be public in order to be of benefit to your business. If you are creating business relationships with 3rd parties, it’s quite easy to make a case on the feasibility and benefit of having them expose an API specifically for your needs.

Q: Using third-party APIs is seen by many as introducing business and technology risk. How do you view this issue and how do you account for it in your strategy and implementation?

A: Anytime you rely on a third-party for your business, you’re taking a risk. You have to mitigate this risk by doing your research and using services from companies that you trust. You have to remain flexible and have a good back up plan. It’s important to incorporate these APIs in way that is either unique or adds a distinct value to your core business model.

Q: 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?

A: APIs are slowly starting to deliver on the reason they were created in the first place. 5 years ago I was spending a lot of development effort creating page scraping technologies and these horrors are still fresh in my mind.

When a company opens up an API, you have to realize that there is probably going to be several thousand other developers integrating it as well. Giveness is not unique because we use APIs, it’s different because we used available API technologies to solve a fundraising problem.

Q: And finally, besides your own service, do you have a favorite mashup?

From a mashup standpoint, Pageflakes seems to have a great framework in place for integrating numerous APIs. It’s a clean design and the personalization features are very impressive. They are very active in the .NET development community and share a lot of their experiences in building their application, so I have a lot of admiration for their work.

I really enjoy a mashup that does something thats really fun. I saw twittervision the other day and was just sitting back watching twitters pop up on a map. Brilliant.

We’ll continue this interview in Part 2, where we’ll get into more details on API reliability, REST vs. SOAP, and other mashup lessons learned. Big thanks to Richard for particpating in our case studies series.

Share This

Posted by John Musser as CaseStudies, Money, Shopping at 12:41 AM | 1 Comment »

September 4th, 2007

Shopping Mashup Case Study: EarlyMiser

The shopping comparison service EarlyMiser is a classic example of a useful eCommerce application built using a set of third party APIs. In this case study interview we speak with EarlyMiser founder Brian DeSpain who gives us the background on this application, its business model, and some interesting insights from their experience in working with web services from some of the leading eCommerce providers including the Amazon E-Commerce API, the eBay API and the Shopping.com API.

Q: What is Earlymiser and why did you build it?

A: Earlymiser.com is a meta comparison shopping engine. It pulls the best prices on products from Shopping.com, Ebay, Amazon and Yahoo Shopping. We built it because no one shopping engine covers all the outlets where you can buy a product. For example, auctions are completely neglected in most comparison shopping engines today. Some great deals can be found there. Ultimately earlymiser.com is there to help consumers find the best price on items and cover enough of the market so that users can be sure that they are getting a good deal.

Read the rest of “Shopping Mashup Case Study: EarlyMiser” »

Share This

Posted by John Musser as CaseStudies, Featured, Money, Shopping at 1:24 AM | 3 Comments »

April 9th, 2007

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?

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?

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?

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?

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.

Share This

Posted by John Musser as BestPractices, CaseStudies at 12:09 AM | 3 Comments »