Ask These Three Questions When You Sell An API

Adam DuVander
Jan. 13 2014, 08:00AM EST

In earlier pieces about APIs where developers pay for access, I've covered methods of pricing APIs and even shared the top three API trial methods. However, some of you are probably not that far along in that process. You may have a good idea for a developer-focused company. Or perhaps your company solved a big issue internally and you want to expose your solution as a new revenue stream. In any case, before you dive into your pricing page and start selling your API, you'll want to consider some basic questions about the problem, your solution and whether you're able to support your potential customers. These are the three questions to ask yourself if you sell an API.

1. Am I solving a difficult developer problem?

Getting a developer to use your API at all is hard enough. If you also want to charge the developer to use it, then you had better be solving a difficult developer problem. Various infrastructure APIs have been successful because they fix a problem not just once, but on an ongoing basis. Consider telephony provider Twilio or email infrastructure company SendGrid (disclosure: my employer). Developers can get started with these services quickly, without going to the effort of setting the servers and everything else necessary. However, even if a developer went to that effort, there would be continued upkeep needed that would keep the attention off the product the developer is building.

Infrastructure is a common example because these are boring problems to most developers. Similarly, Full Contact has had success outside of infrastructure because maintaining contact data is also not terribly interesting to developers.

Any successful company needs to solve a problem for its customers. If those customers are developers—as is the case if you're selling an APIyou have to solve a developer problem. So, as you ask yourself whether you're solving a difficult problem, also consider whether it's an annoying or boring issue that is recurring. If the answer to these questions is yes, that's when you'll find developers clamoring to use your API.

2. Can I charge money for this value?

Once you've determined that you are solving a difficult developer problem, you need to ask whether anyone will pay for the solution. This is very much related to the first question, but is worth asking separately.


Photo Credit:  Tom Hughes-Croucher

Developers have an interesting quirk in that they enjoy solving problems. That quirk is one of the things that makes developers good at what they do. One side effect is that they often want to try to build it themselves. To provide enough value to charge for your API, you need to save developers enough time to make that trade-off worthwhile for them.

Again, a boring and especially ongoing problem is a clear value. Also, if you have expertise in a technology that would be difficult for the developer to replicate, the developer is more willing to see your value. For example, why become an expert in computational perception when there are many image recognition APIs. The same goes for natural language processing, de-duplicated location data and so on.

Even with a clear value over developers doing it themselves, an API's real competition is often open source. Be ready to explain why your solution is better than developers piecing together a replacement of their own solution with an open source solution. Often this can be in the initial setup, the maintenance, or other services you can layer on top.

Another great tool in your arsenal to show your value is your people and their expertise, as discussed in the next question.

3. Will my team be able to communicate with developers?

When your product—or the entire company—is focused on developers, you'll find a whole new challenge of communication. You need to be able to write, speak and interact easily with developers. This role is often hard for fellow developers, a group not known for communicating. It's doubly difficult for non-technical people, because they often lack the common language of code.

I give a presentation on the "Three Cs" to Make Your API Irresistible that gets to some of the best practices for communicating with developers. A lot of it has to do with documentation and support requirements. You need at least one person in your company devoted to communicating with developers if you want to sell an API. More is better.

Take a hard look at these three questions if you're considering charging developers to use your API. There are many successful examples to learn from now, but first you want to make sure you're solving a difficult problem, providing enough value and have a team that can handle the unique communication requirements.

Adam DuVander is Developer Communications Director for SendGrid and Contributing Editor at ProgrammableWeb. Previously he edited this site and wrote for Wired. You can follow him on Twitter.

Adam DuVander Hi! I'm Developer Communications Director for SendGrid and former Executive Editor of ProgrammableWeb. I currently serve as a Contributing Editor. If you have API news, or are interested in writing for ProgrammableWeb, please contact editor@programmableweb.com Though I'm a fan of anything API-related, my particular interest is in mapping. I've published a how-to book, Map Scripting 101, to get anyone started making maps on websites. In a not-so-distant past life I wrote for Wired and Webmonkey.

Comments

User HTML

  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.