Don't build an app, build an API, then build an app.
This is what we did with our product, a CMS (http://www.gethifi.com). We built a very flexible API that has cool things like permissions, relationships and versioning built in. Then we built our app and interface on top of that.
This turned out to have tons of advantages. Our app development went very quickly. It was much easier to do testing. Improvements to the API are now universally available.
On top of all of that, there is an awesome API available for every site on the system!
By inverting the way you think about the API, (build on the API, vs. build an API for an app) you end up with an API that is much more polished as well.
I don’t think it’s a good idea to build an API and then build an app; when you first work on an API and an app, I think it’s important to build the API with the app.
Earlier this year I wrote a blog post that mentioned this[1], but in short: great apps have great user experiences, so working on the app’s user experience should be one of the first things you do. If you’re able to figure out exactly what you’ll need in an API to build the best user experience, then building the API might work for you; however, if you’re still trying to nail down down how your app is going to work, solidifying an API before building your app will probably result in an inefficient API or an API that needs to change.
We do the exact same thing at Flickr. Anytime the front-end needs an method to do something, we'll build it in (though it may not always make its way into our public API).
The nice thing is if we change the behavior of an API method inadvertently, we catch it instantly since the site itself reveals the bugs.
We have the same experience (at a much smaller scale!). We can pull down production sites into a VM to see what happens whenever we make an API improvement. It is a great way to catch subtler things too like performance changes.
Its also an excellent way to think about your app.
What are the core things your app should be doing from a data perspective? Expose those things in an API.
Making the API available over REST or as a Web service is extremely simple, and its amazing how useful it becomes over time in your own development.
It also makes you think twice about changing how these core methods change, which is often a good thing (especially when you are working in a small team and its tempting to make "little" changes to solve your current problem without thinking about its implications).
This is also how I've been building web apps lately. I build the API, then build the app on top of the API. Eating my own dogfood ensures that it's tasty enough for my palate.
This is what we did with our product, a CMS (http://www.gethifi.com). We built a very flexible API that has cool things like permissions, relationships and versioning built in. Then we built our app and interface on top of that.
This turned out to have tons of advantages. Our app development went very quickly. It was much easier to do testing. Improvements to the API are now universally available.
On top of all of that, there is an awesome API available for every site on the system!
By inverting the way you think about the API, (build on the API, vs. build an API for an app) you end up with an API that is much more polished as well.