I had my web 2.0 initiation working for one of our clients, a startup company which was taking the property valuation market of the pacific North West of the US by storm. This company was making money just few months after it went live. They didn’t charge users for the services and Google ads were initially their only revenue stream (Currently they have their own ad server and don’t rely on Google ads anymore). It was quite amazing to see a well grounded startup make the kind of money, just by selling ad space.

A huge database of properties and a carefully crafted valuation algorithm with ample room for users to create content, is what differentiated the startup from established players in that space.

The company had a number of challenges to deal with; the foremost among them was to get people’s attention on the web, which is a critical success factor for any web 2.0 business.

The company spent zero dollars on advertising; they pretty much relied on “Word of mouth” and some good press coverage. One of the things they did was, to decide on opening their services as an API for developers to build applications around it.

I was part of this API team. Number of things had to be considered; as opening up one’s services could well be a death march, if not carefully planned. The intention was to allow genuine users to get the best use of the services, and to check moves of users with ulterior motives. Other considerations were the grading of APIs and users.

The company had acquired data from other third parties. There were restrictions on this acquired data to be redistributed through a service. After toying with the idea of charging users for premium content, it was dropped as it didn’t augur well with the organization’s purpose of empowering users.

Finally after several rounds of discussions, a decision was made to support a basic and a premium API based on the data provided. The basic API would provide valuations, which did not involve third party data; whereas the premium API would provide detailed information on properties. Users, who normally sign up for a developer account would be given just the basic API. In the future, based on their need, they could upgrade this to a premium API. This differentiated users who signed up for the basic service, from being counted in as premium users. Also the API service could be offered for free with fewer premium content users.

Another goal was to control the number of user requests. There was a certain throttle limit that was defined for a user in a day. On crossing this limit, the service would be shut off for the user for that day. Users, who hit the throttle consistently, had the option of contacting the company’s marketing department and request for an increase in throttle limit. Before a decision was taken on raising the throttle limit for a user, usage stats and the nature of the service were reviewed. IP addresses were tracked, to ensure that a person didn’t signup multiple times to go over the throttle limit. It was necessary to make sure that the servers don’t get overwhelmed by somebody who wants to bring them down.

There were some things which were based on good faith. A user is not expected to persist the data obtained from the API or call the API from a backend service.  An account could be blacklisted if the organization came to know of such API misuse.  

I assisted the team in designing storage for the API service. The requirements were constantly changing and it was difficult to close on a design. Initially, we thought of having separate developer accounts for API users. Then, we decided that all API consumers had to be registered site users and developer account would be just a “role” attached to their user account. By this time, I could not continue with the API team, as I had to move to the geographic data team.

While I was working with the geographic data team – getting my hands dirty with points, lines and geometries; news was out that the API service was launched. There was lots of buzz around it! It helped the company in couple of ways: One was branding (as one of the requirements of API users is to display the brand and logo), and the other was the tapping of other user-bases. There was a noticeable increase in traffic to the primary website few months, post the API launch.

One fine day, we heard of somebody who had built a mobile application which gave instant property valuation using the API service with a whole lot of other features. A particularly useful tool for real estate agents on the move! It was surprising to see how people got creative with the API, well beyond what the API designer could have envisioned. The API was a rocking success!

It’s interesting to see the kind of attention a small company, with tons of user generated data and an established user base commanded from existing players in the industry. More often, Buying is an easier option, rather than entering the game late.

I’m not sure how the company is faring today, with the US realty market being spooked. However, the new web with content of the people, by the people and for the people is for here to stay.

Arun J D Devaraj Web 2.0 API, extensibility, Web 2.0