I'm a little more cautious about this and would suggest three caveats: 1. Building an API from day one can be premature. Typically when you start building some

I'm a little more cautious about this and would suggest three caveats: 1. Building an API from day one can be premature. Typically when you start building something is the time when you know the least about the problem you're trying to solve and the issues you'll face solving it. That problem is subject to much more change early than late. If you build an API on day one may just be creating more work for yourself later on; 2. If you provide a public API, you are quite possibly exposing your data model and any assumptions that underpin it. This can make it much harder to change later as circumstances change. Think of it as making everything (including data members) public in class. It's abstraction; and 3. What value does an API provide you as the service provider? Twitter is an easy example of this: it doesn't really matter where the Tweets (sorry nytimes) come from as Twitter owns the graph, the distribution and the Tweets. Now consider a site like Stackoverflow. What if you could ask questions, search for answers, vote, view your summary information and so on completely via an API. What value would there be in the SO site? Not much at all and it's the ads on those pages that pay for the site (well that and $x million from USV).