The Complicated Dynamics Between SaaS, iPaaS, and End Users

The software integration world is weird and interesting. People who aren’t close to it typically don’t even know it exists. Teams that need to buy integration products or services typically don’t really want to do it.

Yet, it’s incredibly important.

The SaaSification of the software industry, emerging frameworks for rapid product development, and lots of capital funneling into the sector have created a huge amount of fragmentation. This makes software integration a non-negotiable capability for any company that uses software (read: any company).

These dynamics have created a complicated set of incentives and market dynamics that are useful to understand.

In this post, I want to break down those complicated dynamics between SaaS companies, iPaaS companies, and the end users they serve.

My goal is to help teams at software companies as well as teams who purchase software for a business to understand what’s happening and how it impacts them as they face critical decisions about how exactly they’ll handle connectivity.

Important Terminology

This software world we’ve created can get a little confusing, because of the terminology we assign to different types of products and companies.

Tech people like to be cute and create terms that are derivative of other existing terms.It sounds awesome in TechCrunch, but it confuses the crap out of a lot of less technical people.

Therefore, before getting into the meat of this post, I want to set the stage a bit, clarifying the characters in this play:

  • Software-as-a-service (SaaS) is a business model where a user pays for a piece of business software that someone else hosts for them, usually on a subscription basis. (If you want to read more about SaaS, start with Salesforce, the people who made it sexy.)
  • SaaS companies are the software companies that build and sell SaaS products. I’m going to specifically use “SaaS company” to refer to the organization and “SaaS product” to refer to the software itself.
  • Integration platform-as-a-service (iPaaS) is a type of SaaS product. It’s basic function is to connect other software products, usually also SaaS, so they can share data on behalf of their users. Likewise, iPaaS companies build and sell iPaaS products.
  • End users are the line of business or subject matter experts who seek SaaS products and sometimes iPaaS products. They have some other business or some job to do and SaaS products theoretically make them better at it.
  • On-premise software or traditionally licensed software describes the pre-SaaS model for the software business. End users buy a version of a product and install it on their own hardware. They either pay the software vendor or a third party to maintain, customize, and upgrade it and/or the end user’s IT department does those things in-house.
  • Platform-as-a-service (PaaS) is something very different than iPaaS and not really important in this post. See comment above about confusing derivative terms.

I’ll try to be as clear as I can as we go, because talking about how all these things relate to one another can be a little bit tricky. Do not hesitate to leave a comment if somewhere I trip over myself or say something unclear.

Why SaaS?

SaaS emerged as such a popular model for software for many reasons, but these are some of the big ones:

  • Setting up and using SaaS products is far easier for end users, because there is no installation, no hardware to provision, and much less need for customization or custom software to be developed than with traditionally licensed and installed-on-premise software.
  • Subscription pricing models produce more consistent, predictable revenue and cash flow. Investors like this. Customer subscriptions are effectively an annuity, so investors place significantly higher value on SaaS companies. Software company founders are therefore incentivized to be a SaaS company.
  • SaaS products tend to be lighter-weight than do-it-all, traditional enterprise software products, but that isn’t a hard rule. This means end users have more choices and smaller decisions to make when evaluating those choices.
  • SaaS products tend to have a lower cost of ownership for the end user than traditionally licensed software, because end users just sign up and start paying. The SaaS company hosts and maintains the software for many end users, so they get economies of scale. They mark it up and charge the end users for it. Everyone wins.

Back in the day, an IT department would make large software purchase from companies like IBM and Oracle for software products that “do it all” for every line of business or part of the company. Software was very centralized and optimized for breadth of functionality, not depth of functionality.

The emergence of SaaS flipped that on its head, because it means there are many software products that do one thing or a few things really well. These SaaS products are way more budget-friendly and way easier to set up, so line of business users just started using them.

This happened with or without the centralized IT department’s permission. To scare CIOs, IT guys even came up with an ominous term for it: shadow IT.

Today, the marketing team finds, builds, and owns their own marketing-focused software. The HR team does the same. The sales team does the same. The customer success team…you get the idea.

No company is completely decentralized with their enterprise architecture, nor completely centralized, but today, everyone has some amount of piecemealness. SaaS simply means companies are using more individual software products to do the things they do.

Enter the Frankenstack.

Why iPaaS?

One advantage to large, centralized software is that it harmonizes the business. It allows you to automate process across all of the different domains the software covers. It usually isn’t that great at any one of those domains, but it checks the boxes and it creates homogeneity.

In an “every team for themself” SaaS world, you start to sacrifice the homogeneity that is the foundation for cross-functional process automation.

Integration platform-as-a-service fills that gap. It’s derivative of products like enterprise service bus (ESB) and enterprise application integration (EAI) tools, tools that helped enterprises integrate legacy software, but iPaaS cloud-native and of the spirit of SaaS.

Here’s where it gets really fun: iPaaS is technically a type of SaaS. It’s a SaaS product whose job is to integrate SaaS products so that an end user can make those SaaS products work seamlessly. Yowza.

iPaaS started to gain adoption over traditional, on-premise predecessors for two main reasons: 1) iPaaS tends to work more out of the box with the SaaS products that users are adopting and 2) iPaaS offers cost of ownership benefits relative to ESB/EAI basically like SaaS does, compared to non-SaaS software.

Let’s review… SaaS got hot, because it solves some big problems in software. Lots of people started buying lots of SaaS. That created a Frankenstack problem. iPaaS emerged to solve that problem.

SaaS + iPaaS + End Users

These three characters have a complex, interdependent relationship. If you are or work for any one of these, it’s important that you understand the nuances of this relationship. It also sets context for future posts where I’ll discuss why any of this is important and where all of this goes. It’s where we’re making bets at Blended Edge.

To understand how everyone relates, start with their motivations.

End users do a job at a company. They want to be as good at that job as possible, so the company can be successful, they get paid well, they get promoted, and everyone is happy. Hooray!

End users sign up to use SaaS products as a way to level themselves up to do their jobs better. (I’m being intentionally uncomplicated. This usually happens at a team or organization level, not the individual level.)

SaaS companies and iPaaS companies are very similar in that their main goal is to build and maintain an annuity of subscription revenue. Therefore their goal is to attract and maintain users who will pay for their products.

The algebra for what that user-sourced revenue looks like varies, but at the fundamental level, that’s the thing. Get users, get revenue, and make sure it’s long-term committed revenue that comes in on an ongoing basis.

However, the SaaS company and the iPaaS company differ in one very significant way. The SaaS company’s total addressable market (TAM) is defined by the number of users who need the thing their product does. The iPaaS company’s TAM is defined by how many users adopt the SaaS products that the iPaaS connects.

The SaaS company can solve a problem, then develop and monetize the market around that problem. The iPaaS company has to ride shotgun. The problem the iPaaS solves doesn’t exist without a market of users solving other problems with SaaS products.

Therefore, the iPaaS company is dependent on the success of multiple other SaaS companies. The iPaaS company can’t win unless they do. It’s a power imbalance that would seem to imply an upper-hand for SaaS.

But, not so fast…

Remember, the SaaS company’s fundamental motivation is attracting users. The end user’s fundamental motivation is doing their job better, which means adopting whatever SaaS tools help them. Also remember that the industry is fragmented and crowded, because of the emergence of SaaS as a business model.

This means that for a SaaS company to most successfully sell their product to an end user, they must be able to play nicely in the sandbox with the other SaaS products that the user chooses to solve adjacent problems. (That’s eight per user, on average.)

Put in different terms, the end user needs the SaaS company’s product to integrate to other SaaS products. Who offers that capability? The iPaaS companies with their iPaaS products.

iPaaS companies need users, but can only get the users that SaaS companies manage to get. SaaS companies also need users. Those users need SaaS products, but they need multiple SaaS products that can talk to one another. Therefore, to get users, SaaS companies need what the iPaaS offers.

If it feels complicated and circular, trust your instincts.

Models for Enabling SaaS Connectivity

The rest of this post will break down these models. Each model has significant implications for each of our three main characters (end users, SaaS companies, and iPaas companies).

It’s also important to note that these aren’t entirely mutually exclusive. A given SaaS company may be part of two or more of these. That said, most companies wind up with a heavy focus on one.

My goal is to help you understand these models and what they could mean for your business and your objectives. The last thing you want to do as any of our three characters is incidentally end up in one of these without having given thought to its strategic implications. Unfortunately, that’s often the story that plays out.

Each of these probably justifies its own post, and that may be on the table. For now, let’s break down the important stuff…

SaaS Builds Native Integrations

This is the easiest place to start from an idea perspective, but it’s usually not the easiest to execute. Of all of these models, this is the one that teams end up in most often.

The product manager says, “The sales team wants an integration to x.” The engineering team, often a hammer that sees a nail, says, “Ok, let’s write code to make an integration to x.”

For end users, this may be a non-issue. If the SaaS product has the integration they want, then awesome! And, if that integration feature was built natively into the product like any other, it was probably done so in a way that feels very natural and well embedded.

But, this model tends to stretch the engineering team around a dozen (+/- 50%) integrations. That means two things for the end user: 1) you quickly start to run into a situation where the SaaS product doesn’t have the integration you need — no time to build it and 2) the integrations start to drop in quality, because of the technical debt, maintenance obligation, and competing priorities the engineering team has to contend with.

The SaaS engineering team took an easy way out (or so they thought) and now the implications of that start to bleed out to the end user.

For the SaaS company, you get the “we have that integration” box checked a few times. You also do without really having to rely on any third parties.

This works well early, for the first few integrations — when you’re still getting to product-market fit and you aren’t trying to achieve hyper-growth. It breaks down as soon as your growth curve starts to turn up.

I can’t tell you how many SaaS companies I talk to who get to around a dozen homegrown integrations and they start realizing the weight of what they’ve done — that what got them here won’t get them there. This moment creates stress and friction in the business.

The iPaaS company doesn’t have much role in this story. However, these are exactly the situations that iPaaS companies look for to offer the SaaS company a way out. Sometimes that way out is magical. Sometimes its not really in the SaaS company’s best interest.

iPaaS as Lone Operator

iPaaS companies must find users to pay them subscriptions, so their incentive is to find markets of domain-similar SaaS products where end users’ options for connectivity are limited.

The rest of the models this post will talk through involve some sort of direct relationship with the SaaS company. But, iPaaS companies are also able to go build their own markets. Many do.

To be successful, the iPaaS company must be smart about the competitive landscape. They must evaluate non-binary tradeoffs like:

  • Relative few integrations with deep functionality or relative many integrations with shallow functionality?
  • Integrations focused on a certain specialized niche or integrations that service a wider, more generalized market?
  • Configuration and maintenance functionality that appeals to non-technical business users or to sophisticated engineers?
  • Priced as a premium offering or priced for aggressive customer acquisition?

To some extent, every SaaS company faces these tradeoffs, but the iPaaS company has a uniquely challenging version of them to contend with.

Remember, the TAM for an iPaaS is only derivative of the TAM of other SaaS companies. The iPaaS is useless without SaaS products who have end users who require integrations.

As the iPaaS narrows in on TAM it has identified, it must get those above tradeoffs correct. If not, you’re trying to sell a premium product to a commodity crowd, a generalized product to a crowd that wants deep domain specialization, or a low-code business tool to engineers.

Again, the iPaaS company doesn’t control any of this. They have to be superb at discovering (not building) a blue ocean and then executing on it with superb customer development and product management — making the right choices about those tradeoffs, relative to the ocean they’ve discovered.

SaaS companies have kind of an awkward spot in this model. Of course, they are part of the equation, but they don’t have any direct relationship with the iPaaS companies to enable connectivity. It also means they have limited answers for end customers who request it.

SaaS builds native integrations and iPaaS as lone operator will typically happen together, and it’s mostly because both parties have failed to develop a common ecosystem. It’s also probably not likely to stay this way for long, because both parties have incentive to get to a more effective model.

End users suffer here too. They already have the difficult task of assembling a stack of SaaS solutions that meet their business needs. Now, they also have to evaluate iPaaS solutions.

End users typically see integration as a necessary evil, no matter how effectively iPaaS vendors market it as a strategic value-add. End users want seamless experiences that move across the SaaS products they’ve adopted. They don’t want integration.

So, asking them to search, evaluate, and pay for something that only provides integration isn’t popular.

SaaS + iPaaS Partnership

Recognizing this, SaaS companies often seek partnership with iPaaS companies (or vice versa) to provide a better answer than 🤷‍♂ when a user asks about integration.

These partnerships usually include some/all of:

  • Referral agreements for sharing customers with the other party
  • Certifications or informal credentials to pump the legitimacy of the partnership
  • Joint marketing efforts online and offline
  • Overlap in operations — team members getting to know each other, knowing how to work well together, etc.

You know…all the things you hope for with a good tech partner.

iPaaS companies definitely like this. It’s direct access to their TAM. These partnerships are often a significant channel for revenue growth. Ideally, the SaaS company will form a bunch of these, a few of which will by an order of magnitude more lucrative than the others.

SaaS companies also benefit from this arrangement, because they can bring in a trusted partner when the connectivity question comes up in the sales process. This is especially helpful when integrations are higher touch or more bespoke (e.g. you sell into the enterprise). The SaaS vendor is able to build more confidence that they and their friend can deliver the overall needed solution.

The SaaS company also gets to punt on integration to some extent. They’ll still need an API or proper way to get data into/out of their product, but they don’t have to worry about the last mile. However, it’s not all roses and rainbows…

End users don’t always find this to be a wonderful experience. And, a less than excited user is still a negative for the SaaS company.

Remember, users don’t want integrations. They want seamless cross-product experiences that help them do their jobs more effectively.

“Yes, we can connect our product to x, if you pay our friend y to do it,” is a better answer than 🤷‍♂, but it still asks the end user to form a commercial relationship with and shell out dollars to an iPaaS company that they probably prefer not to deal with.

I’ve sold that iPaaS before. I can tell you first-hand, there are a lot of users who are frustrated about that part of the project. Integration projects already aren’t fun (for most people). Paying for it is even less fun.

This adequate, but unexciting answer to the end user’s connectivity questions paved the way for two other models. In the last two models, the SaaS company takes back ownership of integration use cases, but without the shortcomings of the DIY approach already discussed.

Embedded/OEM iPaaS

A new class of iPaaS has emerged, called embedded or OEM iPaaS. Some of these companies are new and dedicated wholly to being embedded. Others are traditional iPaaS companies adding features to enable embedding.

With embedded iPaaS the software in place is the same. The user wants the SaaS product and uses it to address a business need. The user gets the iPaaS product to connect that SaaS product to other systems.

The difference with embedded is the commercial relationships between all of our three characters. The customer for an embedded or OEM iPaaS isn’t the end user. It’s the SaaS company. They license the iPaaS on behalf of their users, so that they can bundle connectivity right into their offering.

This may manifest as simply a bundling/reselling thing, probably with the SaaS vendor taking on the work to use the iPaaS to enable conenctivty.

However, the word “embedded” is used, because the more compelling solution is for the SaaS company to embed or white label the iPaaS into their own product, so it appears as if they built it. This creates the most seamless experience for the end user.

This works great for end users. They get what they want, and they don’t have to pay for it — not directly at least.

This is also great for the iPaaS company for a bunch of reasons:

  • The unit economics of embedded iPaaS are far better. Your marketing requires that you sign up an order of magnitude or two fewer customers to hit the same revenue number as a traditional iPaaS business. You’re dealing with $2,000 to $50,000/month customers (to generalize), not $100 to $1,500/month ones.
  • Your customers are more technically sophisticated than typical end users. They are also typically motivated differently. End users see integration as a necessary evil. SaaS companies see it as a necessary growth lever.
  • While your server and data costs are higher per customer, your overhead should be lower. Again, fewer customers who are more able to help themselves than a typical end user.
  • You lock in customers that have a very hard time leaving, because you lock up your customers’ customers.

Most of the serious iPaaS contenders on the market are pushing an “embedded” or “OEM” model hard, right now. There is a reason for this.

SaaS vendors, on the other hand, are put into a position to make a very big tradeoff. If you assume that most of your users will require integration, taking an embedded iPaaS approach means that you put most of your users in someone else’s hands, but on your behalf.

If that iPaaS stops performing well or goes out of business, your users are stuck.

If that iPaaS wants to triple the price they charge, the SaaS company is stuck. Would you want to call all of your customers to tell them that their integration is going to turn off at the end of the month?

If the iPaaS wants to sell their embedded offering to a competitive SaaS company, they actually make the switching cost lower. Again, the SaaS company is stuck.

These are significant risks to consider. Those risks may also have impact on the enterprise value of the SaaS company, and important consideration given that many SaaS companies are venture-backed.

Now, these tradeoffs aren’t for naught. There are benefits to this model for the SaaS company too.

The SaaS vendor will be able to provide integration capabilities that they could never build themselves. Not to dig the SaaS vendor, but of course they couldn’t! If they aren’t an integration company, why would they develop a best of breed integration product?

Not only are integration platforms hard to build — and most SaaS companies are unequipped to build them — they are expensive to build. They require a lot of capital, because the difference between “nothing” and a minimally usable product is pretty far.

SaaS companies basically get to rent all of the benefits that an iPaaS brings without having to go through the pain of building an iPaaS.

iPaaS Capability via M&A

The SaaS company can acquire an iPaaS company.

You’re starting to see this more often, especially as the capital markets get a little frothy and as the iPaaS industry overall gets a little over-built.

Salesforce acquired Mulesoft in 2018.

Hubspot acquired PieSync in 2019.

Qlik acquired Blendr and Celonis acquired Integromat in 2020.

Oracle/Netsuite acquired FarApp in 2021.

This is a topic for a future post, but this M&A blitz is only the beginning. I expect at least a dozen more iPaaS companies to get gobbled up by SaaS vendors or private equity firms over the next few years.

For the SaaS company, this is probably the best way to solve the connectivity problem, assuming the company is mature enough for such an acquisition.

It’s certainly a more capital intensive approach, but you pay more now to pay a lot less over time. The unit economics for many of these iPaaS companies are strained, so the valuations you’ll make acquisitions at may not even be that impressive. There are discounts to be had for SaaS companies with the capital to make an offer.

This can be a big win for the iPaaS company as well. You don’t really see iPaaS companies go public. There’s a reason for that. The unit economics of the business are not sustainable enough to be a public company — or at least no one has really figured out how to make that work.

Talend, arguably an iPaaS, is the only notable exception that comes to mind, but they were just brought back to private equity this year.

As long as the iPaaS company gets a reasonable valuation on the sale, this is a win for them. The company rolls into a bigger solution with a more sustainable future and theoretically the iPaaS’s investors make some bank.

End users might get left with the bag though. Let’s say SaaS company x acquires iPaaS company y. This is great for users who are signed up for x and y. But, it may not be so great for all the iPaaS users who don’t and don’t want to use SaaS x.

With an acquisition like this, there’s a big question about how long the iPaaS business will be allowed to operate as a standalone iPaaS business. When a SaaS company acquires an iPaaS, it may want to transform into the SaaS company’s built-in iPaaS. They won’t be all that concerned about providing integration capabilities for competitors or irrelevant other SaaS providers.

Whether the SaaS company lets go of or sells off any amount of the iPaaS business is a big question. It may never happen. It probably will happen.

This puts at least some of the end users in a precarious position, potentially requiring them to go find a different integration solution.

It takes two to tango, but there are three people in the room.

When you look at the three models for how the SaaS integration dance plays out among our three main characters, you see that in all cases two of the parties end up in a better place than the third. (Or, they at least have a stronger strategic position.)

Someone always ends up as the wallflower.

Integration is something that nobody wants, but everybody needs. That reality forces SaaS companies, iPaaS companies, end users into a three-way game of hot potato.

While this is certainly an interesting dynamic to dissect, that’s not the point here. Understanding this ecosystem and its dynamics is an important foundation for some future posts I plan to write on topics including:

  • What happens as the iPaaS industry consolidates?
  • What does the world look like post-iPaaS?
  • Why do we care at Blended Edge? Why should you care?

Subscribe to stick around, if you want to go on this very inside-baseball journey with me.

Cofounder and CEO of Blended Edge. Singer/guitarist in Local Tourists. Head of Guitars Not Guns Ohio. Ohio born and raised.