We’ve come a long way

Enterprise software has seen a number of key shifts in the way that it’s built, distributed and consumed. From the days of on-premise hosted solutions, with bespoke code and teams of consultants required for efficient operation, through to today’s cloud-based solutions with a focus on great user experience, next-to-no onboarding effort and far more flexible pricing for customers.

But just as the world is waking up to the importance of design and user experience in enterprise products – arguably years after the consumer market saw the same evolution – there is a new breed of B2B solution, which ditches the visual user experience altogether – the API-based SaaS.

What is API-based SaaS?

There are a few, rather hard-to-miss features of such a service:

• There is NO user interface (GUI). Or in some cases, there is a GUI but it’s secondary to the core product.
• Interaction with the service is through a web-based API – a programmatic way of connecting services and transferring data across the web in a machine-readable way.
• The value of the service is usually in the data that’s delivered (through the API).
• Pricing is often usage-based, meaning that the cost is based on the number of requests made to the API.

Some examples

Clearbit

Clearbit is building a collection of Business Intellgence APIs with the goal of becoming the BI backend for many businesses. As with most API-based products, the value is in the data that Clearbit provides, through a simple, easy-to-consume interface.

Tip: Listen to the latest episode of SaaS Open Mic, a podcast dedicated to sharing the stories of SaaS founders and thought leaders. In this episode I chatted with Clearbit Co-Founder and CEO Alex MacCaw, on why he believes API-based products are set to become the next generation of enterprise software:

Contentful

Contentful is a new breed of CMS which is built for the multi-device world we live in today, unlike many ‘traditional’ CMS products. How does it manage that? Through an API, of course! The Contentful team have stripped away much of the complexity around managing content in a device-agnostic space.

Twilio

It looks like Twilio is set to become the first truly API-based SaaS to IPO in 2016. The platform has grown significantly in the years since it’s first funding round in 2009, and now runs the telecommunications infrastructure for major corporations like Coca Cola, Uber and EMC2. And all through an API!

Algolia

Algolia offers an API for search, allowing SaaS vendors to effectively outsource the complexity of handling advanced, high-performance search in their apps – something that’s technically very hard to achieve. The search functionality in apps like ProductHunt, Medium and Birchbox are all powered by Algolia!

What are the benefits for vendors?

API-based products are sticky

Once integrated into your platform, there is a very real ‘pain’ in stripping out the functionality and replacing it, either with another product or with your own business logic (that will inevitably need to be developed by your engineering team). This could mean that, even in the case where a cheaper (or functionally superior) solution exists, there still may not be enough of an incentive to make the switch to such a competitor.

More focus on the value provided

It’s very difficult to add ‘marketing fluff’ around an API-based product. Consequently, it’s much easier for customers to clearly see the value that the solution is adding to their business, particularly when the solution is simply providing them with some data.

Easier to build & maintain

If you’re building an API-based SaaS product, there are some key things you don’t need to consider, for example:

• Designing the perfect UI
• Accommodating multiple browsers and screen sizes
• Creating in-app onboarding & tutorials
• Building a native mobile app

Of course, that’s not to say that everything is easier with an API (see the challenges below), but you have a great opportunity to run a largely simplified software stack that can scale to a large amount of requests.

The customer can apply their own user experience

Businesses consuming your API can have a much greater level of control over how that functionality is delivered to the user. They can brand it in a way that matches their creative vision for the product – leading to an overall more consistent experience.

What are some challenges?

Onboarding

If the goal of your onboarding is to get your customers to their “Aha moment” as quickly as possible, this can be challenging when the customer is required to spend development time on integrating your API before that can happen. There’s much more risk of poisoning the onboarding experience.

I spoke to Sascha Konietzke, CEO at Contentful, to get his take on some of the challenges of building and growing an API-based product, particularly when onboarding customers. Here’s what he had to say:

One common strategy for getting around the challenges of onboarding is to offer a set of integrations with existing platforms.

This is especially useful where there is a fairly common set of use cases for the API, and they involve integrating with an existing service. You’re essentially doing the work (of building the integrations), so that your customers don’t have to. The end result is often a ‘one-click’ connection rather than weeks of development and testing.

Example: Clearbit provides pre-built integrations with Google Sheets, Close.io, Salesforce, Marketo and Slack.

Longer sales cycles

This is directly tied to the difference in Onboarding. Persuading a customer to commit to integrating an API and fitting the required work into their development cycle is clearly a higher barrier than getting them to click sign up in a polished user interface, and enter their payment details.

You’ll also need to think about extending your trial period to account for the increased effort in onboarding.

Pricing – Less flexibility

You’ll have significantly fewer options for pricing your service. Typically with data-oriented services, you’ll see scalable volume-based pricing, i.e. on the number of requests you make to the API. When products are unboxed into API-based micro-services, you’ll find it difficult to scale pricing based on features or other factors.

On the plus side, instead of one product with lots of different pricing dimensions, you’ll be left with a set of smaller products, each with their own, more simple pricing structure. It’s a great way to let your customers pick and choose the different parts of your solution they’ll need, and only pay for what’s valuable to them.

Example: Contentful is priced based on the amount of data entries you store with them, and the number of requests you make to their API.

Marketing – It’s not at all visual

Marketing a SaaS product is a lot about finding ways to convey (and visualize) the value of your solution to the target customer. Even your product has a highly visual, well-designed UI, that job isn’t easy at the best of times. But remove that UI entirely and you’re left with next to no way to really show the product to your target customers. The solution? You have to find a way to visualize the value that the product delivers, rather than the product itself.

You’re also likely to be marketing not only to business owners and decision-makers, but also to developers – they’ll be the ones faced with the task of integrating your API. You’ve got to win over both of these parties if you really want to sell your product.

Example: Twilio goes all-out with developer conferences, swag and an awesome knowledge base of code samples and interactive integration guides to win over the hearts of developers.

So should I ‘unbox’ elements of my SaaS product into an API?

So it’s fairly clear that there are great benefits to both selling and consuming API-based products. But what if you already offer a ‘full-scale’ SaaS solution, should you consider offering parts of this as standalone services? Here are a few questions you should consider first.

Are there areas of my product that could be broken out into smaller, standalone services?

Are there small areas of your product that deliver some isolated value to your customers? These are prime candidates for unboxing and offering separately, through an API.

Is the value of my product tied to the data it provides?

If the answer is “yes”, you might want to consider giving access to this data programatically (through an API), and enabling customers to build platforms and services on top of your data.

Is my product often used as a core part of my customers’ solutions?

If this is the case and you see businesses building additional value on top of your solution, they might be able to do this more easily if you offer this part of your product through an API. The Holy Grail of many SaaS businesses is to become a platform or an ecosystem – You only have to look at the Salesforce AppExchange to see that this unlocks a world of possibilities.

In conclusion: These are the building blocks of the future

The movement towards SaaS businesses delivering value through an API might not appear to be something huge, in the grand scheme of things. There will always be a need for products and services that can be used by humans, with some form of interface through which they can interact (even though there are subtle changes in that space, with strong growth in instant messaging-based apps).

However, when the ‘next generation’ startup approaches the mammoth task of building their product with limited funding and time, there will be a new option on the table for them:

• Use API SaaS A for my email
• Use API SaaS B for my support
• Use API SaaS C for my business intelligence
• And so on…

And there we have the new generation SaaS, built using the building blocks of a range of existing API-based services, that can:

• Launch their product more quickly
• Add pieces of advanced functionality without in-house expertise (e.g. machine learning)
• Evaluate the cost of their service more predictably
• Scale more reliably

We’re already starting to see this, even with some more well-established startups. But it’s likely that we’ll see it to a greater extent in the coming years, as more and more pieces of functionality are suitable for ‘outsourcing’ through an API.

The only question that remains is “what, if anything, will still be built from scratch in 5 years?”