The Unbundling of Traditional SaaS Products

A couple of months ago I wrote an article highlighting 3 trends in the SaaS industry and one of them, “Unbundling of SaaS”, lead to some interesting discussions that I want to sum up here.

What’s the unbundling of SaaS ?

By “unbundling of SaaS” I refer to the increasing number of startups which are offering software packaged as an API instead of a traditional finished product.

A good example is the “support” vertical with several products like supportive.io or supportify.io which “API-fied” the features of traditional support software (like Zendesk) so that you can create your own support experience without having to code everything from scratch.

And an increasing number of products are unbundling more and more traditional SaaS features in different verticals (marketing, analytics, support, accounting, sales…)

Check the “unbundling of SaaS” branch on this mindmap for more examples.

How do they differ from traditional APIs?

Traditional API startups like Stripe, Sendgrid, Twilio etc… are more “infrastructure” APIs which help developers build the “core” features of their product (I need a search on my website so I’ll use Algolia, I need to send emails so i’ll use Sendgrid, I need to accept payment so I’ll use Stripe) which can differ from the APIs I’m speaking about:

• “Unbundling APIs” don’t necessarily target developers first. Very often it’s the marketer, the support team or the salesforce which will request specific “in-house” products to make their life easier.
• These APIs are very often used to build internal tools
• These APIs compete directly with “packaged” products and not directly with other APIs

Challenges for these startups

Need

The first question which comes to mind is the question of the “need”. Is there a real need for such products?

Potential use cases:

1. build internal products instead of buying finished SaaS products = the classical “I’m not happy with any support solution so we’ll build it internally”
2. build internal “complementary” products = a trend which is growing, e.g you have a support solution but you are not happy with some features, so you can build specific internal products to solve that and keep your Zendesk as your main tool.
3. offer new features to your customers without developing them in house = make sense for a lot of features which are generic across many types of products, like analytics, contact management etc…

So yes, there are needs, but the market still requires to be evangelized (especially #1 and #2) and it’s not clear whether these are “niche” problems or not.

User onboarding

• these are technical products (APIs used by developers) which target non developers first
• How do you tackle user acquisition and close the decision loop (attract the marketer, support team etc… and convince the developers to use your API)
• how do you compete with traditional SaaS products (which are easier to set up / use at first)?

These products are API first but they probably cannot skip creating a “killer” app that people can use out of the box and later convert them to their API (Fullcontact is a good example for that)

Can big businesses be build out of this trend?

The cons:

• these are niche products, so potentially hard to scale
• their hybrid position between a real developer API and a pure SaaS product make them hard to market and to sell

The pros:

• the SaaS industry is saturated with thousands and thousands of products which are very often barely different from each other. The future belongs to hybrid products which enable customers to create their own experience tailored to their own needs. And not the “one size fits all” model.
• the “do it yourself” software movement will grow as the tools are getting easier and easier to use and as more and more people learn technical skills (from marketers to sales…). Unbundling of SaaS is just a first step toward that direction.