An API Isn't Enough: You Need an App Directory

This guest post comes from Alex Willen, Developer Advocate at Alex works with the Box Platform, improving its usability and evangelizing it to developers.

So you've decided to put together an API, an excellent choice which I applaud. While this is an enormous step in the right direction, hopefully you're aware that the there's much more to be done--more, in fact, than I could begin to cover here. Instead, I've got one thing for you to focus on today. An app directory.

The why is simple - a directory is beneficial to both developers that are building apps on your platform and to your users. Your developers want people using their apps, and a directory works to that end by giving them a place to show what they've built to your users. Your users want tools that will make their experience using your service better (they might not even know it yet, but they'll be happy when they have them), and a directory gives them a place to find those tools.

Think about this from the perspective of your average, individual developer. He has neither a highly-trafficked blog nor a heavily-followed Twitter account. He codes because it's something he enjoys doing and because he likes to create. He'd love to have people use what he Builds, but he doesn't want to spend time marketing and promoting, because that's time he could be creating. Thus, if you can offer him free marketing that requires no effort on his part, of course he'll be appreciative.

Now take the perspective of a user of your service. Unlike the developer, he doesn't necessarily have any idea what he wants. He'd agree with the notion that your service should do as much as possible, but it's unlikely he could define for you what "as much as possible" should be. He certainly doesn't know that there's a third party developer out there who's built a mobile client for your service that would make his life easier. If he did know, though, he'd be happier with your service (without taking up the time of your already stretched-thin team), and so would the developer, who would now have a little bit more exposure. Thus, you should take it upon yourself to help that user find the time-saving application that he doesn't know he needs by providing him with a place to look for such a thing.

"But I do expose third party apps," you say, "I write about them in our blog!" This attitude is, sadly, far too common. If you think this is an appropriate way to address the issue of advertising applications to your user, you are, to be blunt, very mistaken. First of all, most of your users aren't reading your blog. Second, blogs are formatted in such a way that the most recent information is conveyed as the most valuable. The problem this creates is that the aforementioned Android client, for example, does not diminish in utility as the blog post about it falls onto page ten. An app directory, on the other hand, is formatted with the understanding that the most valuable things in it are the most used or the most highly rated (though they can still be sorted chronolgically, alphabetically, or any other way you see fit to let your users browse them).

Hopefully the value of an app directory is now apparent to you. So why doesn't everyone have one, then (I'm looking at you, Twitter)? There's a simple explanation for that, too--building one takes time, which tends to be a scarce Resource. Rather than use time, you can use money. Sites like do all of the work of creating an app directory for you and minimizing the time you have to spend maintaining it.

I know that choosing to spend either time or money isn't exactly an easy solution, but an app directory is an important thing, and important things are rarely free. In the end, you'll have to choose how to use your resources, and when resources are limited, those choices will be hard. I implore you, though--if you have an API, build an app directory. Think of it like API Documentation. You'd be silly to build an API without documentation, and you'd be silly to build one without a directory.

Be sure to read the next Best Practices article: How Zappos Drives Internal Innovation With Its Public API