From development point of view

The API-first approach is already popular among developers. From technical point of view, there are significant advantages to build an API before a ready-to-use app:

  • The obvious: an API allows you to build a common core that can be used on multiple platforms (website, mobile apps, plugins, etc.). Each time you want to expand your product to a new platform, half of the work is already done.
  • It improves developer’s productivity by hiding complexity. It helps you separate different concerns, especially between front and back ends. You no longer have to deeply understand how things are working, just to know how to use the APIs built by your colleagues.

In short, using APIs to develop a product improves your productivity with a cleaner and more agile architecture.

But what about API-first approach for marketing? Should you open an API to your customers from day one?

From marketing point of view

When we launched Email Hunter 4 months ago, we launched the API, and a very minimalist app (it let anyone make a domain search to get email addresses, without any filter or export feature).

The API and the minimalist tool were complementary.

  • The tool let everyone – technical or not – test our product instantly and have their AHA moment (“Wow! I found 236 email addresses! That’s awesome!”). It generated a great word-of-mouth and has contributed to our success on Product Hunt.
  • The API made most of our first sales. Each customer was able to adapt the service to their tools and needs, whereas our own tool was still too minimalist to be sold alone.

More recently, we worked on our metrics and wanted to know what were the main parts of our services paying customer were using. Although we had improved our web app and launched a Chrome extension, we were surprised to see that the API was still our most important source of revenue.

Email Hunter usage repartition

Selling directly an API has many advantages:

  • You can release your product faster, building only the core of your product without user interface. Also, letting people build with your API will give you clues about what kind of app(s) you should create. Sometimes you discover uses cases you never thought about.
  • It enables customers to create their own experience tailored to their own needs, integrated in their internal tools or other SaaS products.
  • A growing part of non-technical people try to use APIs and build tools themselves. It is facilitated by transversal SaaS products like Slack, Zapier or Google Spreadsheet. These people will be glad to learn they can find their own hacks using your service.
  • Once customers have integrated the API in their workflow, they are less likely to leave. And retention = growth, right?

However, this approach has also a few downsides:

  • Your targets may be marketing, sales or HR people, which will directly benefit from the value of your product. But in most cases developers are the ones building with your API. You have both to draw attention of your target and appeal to developers who will integrate your API.
  • Typical use cases may be harder to identify, as the API can be integrated in multiple different contexts. You need to be proactive talking to your customers and creating appropriate content to help customers use your API depending on their needs.
  • Your API may be on a niche market, potentially hard to scale.

François Grante
François Grante