The Cost-Value Trade-off and Why iPaaS is Hard
We’re about to go through a period of creative destruction in the integration software industry, currently heavy with vendors calling themselves “iPaaS” (integration platform-as-a-service).
I believe that the unit economics of an iPaaS business are extremely challenging. We’re starting to see a wave of closures you probably don’t hear about, acquisitions you probably will, and general industry consolidation.
To name a few examples:
- Boomi, previously acquired by Dell, spun off to private equity
- Talend acquired by private equity
- Integromat acquired by Celonis
- Blendr acquired by Qlik
There’s a reason you don’t see publicly traded iPaaS companies, Talend temporarily being an exception. The unit economics are difficult and don’t tend to lend themselves to metrics that support an IPO.
In this post, I want to break down why I think an iPaaS business is a really challenging one to make successful. In future posts, I’ll get into what I think that means for users who rely on iPaaS vendors to enable connectivity and for those software vendors whose products are being connected via iPaaS.
What is iPaaS?
If you really want to dig in, simply Google this question. You’ll have more SEO-optimized blog posts from various iPaaS vendors than your heart could ever want.
Just to level-set for this post… An iPaaS is a cloud-based software product that has the job of configuring data integrations between other software products, usually also cloud and usually via their APIs.
iPaaS vendors come in all shapes and sizes, but generally share some common attributes: low-code configuration editors, pre-built connectors to the systems they integrate, operations and logging centers, and authentication management. Many are now also touting “AI” and “big data” features. Judge the legitimacy of those features yourself. Some iPaaS vendors are generalists, and some focus on specific industries or niches.
iPaaS vendors sell to teams who need to move data, automate business process, or integrate experience among many different business applications.
An iPaaS is not usually a great fit for one-to-one integrations, but they’ll sometimes still gets used for those types of projects. iPaaS is typically used for many-to-many integrations — think, automating processes inside an enterprise with many applications.
Which brings me to an important point: for an iPaaS vendor, more connectors means more integration use cases you can support, which means more potential customers.
How iPaaS Makes Money
There are a few ways iPaaS vendors charge for their services. Those few ways account for most of the iPaaS products on the market.
- Subscription pricing based on certain features used, number of connectors used, or number of integrations deployed.
- Usage pricing based on how much data moves through the or is stored within the iPaaS.
- Purchased chunks of capacity — basically usage pricing that is pre-sold in batches.
The revenue model is very much like traditional SaaS (software-as-a-service). Recurring revenue streams, 12–24 month contracts, high margins, high growth, and low churn seek to generate 10x to 30x valuations based on top-line revenue.
Most iPaaS vendors also provide professional services for building new connectors, building new integrations, and generally enabling success for their customers.
Professional services are not as high margin nor valued as highly in the capital market, so this usually isn’t intended to be a primary revenue source for the iPaaS.
I’m willing to bet that many iPaaS vendors depend more on professional services than they like to talk about. Most iPaaS companies are privately held, so it’s tough to see this breakdown.
Different post for a different day.
Building an iPaaS
Building an iPaaS product is no small feat, because it requires a heavy burden of technical expertise and a lot of upfront work that hopefully pays off later.
If you break it down to the basics, an iPaaS contains two things: 1) a platform that knows nothing about the systems it’ll integrate but knows how to do all the things required to move data between them and 2) a set of connectors that allows that platform to send data to and receive data from each possible endpoint system.
I’ve written about connectors before, and I have strong opinions about them. For this post, I’m using the term pretty broadly.
The connectors are useless without the platform. Who cares if you can talk to an external system if you can’t do anything with that conversation?
The platform is useless without connectors. What use is software that can move data between systems but can’t talk to those systems?
Therefore, to get off the ground, you must invest in both.
The Value of “One More Connector”
Early on in the life an iPaaS, adding one more connector to an iPaaS product is a pretty big deal. Obviously, having one connector is useless. The second connector offers the business pretty massive relative value, because now they can address an actual integration use case.
As you continue adding connectors, you continue unlocking new business opportunity, and early on, each new connector still represents a relatively large chunk of value.
One reason the value added from early connectors is big, is because the iPaaS producer is incentivized to start with the ones that unlock the biggest market opportunity.
Take CRM connectors, for an example… Adding Salesforce, then Hubspot, then Dynamics CRM are all big deals. They unlock a lot of potential customers who may have interest in your iPaaS, because they are well adopted products themselves.
But, this steep hill of adding value with every connector doesn’t last forever. There’s a long tail for each category of systems you’ll build connectors to. As you build connectors, they become increasingly niche, used by fewer people. That means that each connector you add is gradually less valuable to your company, relatively speaking.
It’s the law of diminishing returns.
If we plot the relative value of adding “one more connector” over time, it’ll look something like this:
The Cost of “One More Connector”
Connectors don’t grow on trees. You must invest in them. Someone has to build them, whatever “build them” means for your iPaaS.
Let’s start with a few assumptions:
- There is no such thing as building a connector (or anything for that matter) that costs $0 or less than $0.
- More code = more maintenance responsibility = more cost of ownership.
- More connectors = more use cases = more corner cases that the platform potentially has to support.
The connectors are ultimately the value-driver, but the platform is prerequisite. As you progress, you are investing in the platform alongside building new connectors. “Adding one more connector” also means adding some amount of platform functionality too.
Early on, like the value of adding a new connector, the cost of adding a new connector is on a steep incline. That’s because you are also building out the fundamental platform capabilities alongside the early connectors. It’s also because you are still learning how to build connectors successfully. It’s inefficient, early on.
As the platform matures, less new platform functionality is required. You continue to add connectors, but less investment is put into the platform itself. At that point, you’re really only making platform investments to address incremental corner cases and dealing with technical debt. The big stuff is mostly behind you.
You also will usually start to get better at building connectors. Your tooling or SDK will improve. Your process will improve. Usually a more stable platform makes for easier connector development, and your maturing platform will be more stable. Your team will also just get generally more experienced with building connectors.
This might lead you to believe that this whole process leads to highly capital efficient connector development program that enables the iPaaS to grow market share by building “one more” indefinitely.
Technical Debt and the Cost Curve
It’s virtually impossible to reach a fully optimized connector output where the “cost of adding one more” is absolutely as small as it can be. (Remember, it can’t be zero.)
I believe that most iPaaS vendors even fail to bend the cost curve downward whatsoever.
This is largely because of technical debt.
Every time you add a new use case, a new connector, a new feature on your core platform, or anything else you add, that additional code means high potential for technical debt.
Other indirect costs increase as well. It’s harder and harder to market and to sell a massive library of connectors. Hard means expensive. Growing your connector library indefinitely gradually increases overhead demands for your business.
In the best case, this just means upward pressure on your cost curve that you are otherwise pushing down through efficiency. In the worst case, it actually means that the “cost of one more connector” starts to increase and even accelerate. I believe many iPaaS vendors are experiencing this upward pressure, maybe more so than they even see.
Preventing that upward inflection is not easy. It requires really good platform design, really good process discipline, and really good engineering.
When the “cost of one more connector” starts to grow out of control, the iPaaS business starts to spin out of control. This is where the entire iPaaS business model starts to break down.
This is when iPaaS gets hard.
When the Cost Exceeds the Value of “One More”
At some point, the cost curve intersects with the value curve. This is a meaningful point for the iPaaS business.
This point should imply that the iPaaS has basically maxed out its ability to grow market opportunity by building connectors — that it has reached its most efficient number of connectors to have, given its cost realities when building “one more”.
Any step you take past this intersection will likely start to erode the business. In basic ROI terms, each new connector past this point ends up costing you more than the value it’ll generate for the business.
This doesn’t mean the company ceases to grow. It simply means it should stop (or at least significantly slow) new connector development. Now, growth becomes about taking as much share as possible within the current connector-enabled market, adding up-sellable platform features, and maximizing profitability.
Assuming you recognize the point where “one more” costs more than the value it brings and assuming you are able to operate profitably at this point, the iPaaS business becomes a reasonably stable cash cow. You can reduce R&D cost maximize profitability.
(Getting to this point is a win, and far from easy to achieve. Massive kudos if this is you!)
But, what if it still isn’t good enough? What if you can’t make the decision that you’re big enough? What if that decision itself will cause you to fail, because becoming a cash cow doesn’t mean “success”?
Venture Investors + iPaaS
Remember the start of the cost curve? Each new connector is pretty expensive early on, because you are also building out the core platform that allows any of those connectors to have value. Both the connectors and the platform are required, because neither alone is useful.
That steep cost curve means that it’s very difficult to bootstrap an iPaaS business. The unit economics are typically that of a traditional SaaS business where the cash flow potential per customer isn’t high enough to sustain the business until you hit a critical mass of customers.
It’s worth your time to read David Skok’s post on SaaS metrics, which explains this paradigm.
All of this means that many (most?) iPaaS businesses are built on investor dollars, usually venture capital. And, that means that the potential outcomes for the business are limited, compared to a business that has bootstrapped itself and remains founder-owned.
Venture capital means you need an exit. Venture capital means looking for 10x to 30x revenue-based valuations. Venture capital means optimizing to enterprise value, not profitability.
These requirements conflict with the suggestion to stop when the cost of building one more intersects with the value generated by building one more.
When you’ve reached that intersection, if the business can’t be exited for a value that returns investors an appropriate amount of capital, they probably won’t be happy with slowing R&D to operate in cash-generation mode.
The iPaaS vendor will almost certainly be pushed to go further. Build more. Operate at a loss for the sake of growth. Do things that don’t scale!
This creates some challenging situations:
- The business becomes a timebomb. This mentality may get the iPaaS to an exit, but the higher likelihood is that it leads it to an unsustainable situation where it operates with negative cash flow. The growth for growth’s sake can only carry the business so far.
- Technical debt is already a natural force pushing the cost curve up. Massive growth expectations (past the cost-value intersection) are likely to obligate the iPaaS team to largely deprioritize technical debt concerns, bending that cost curve upward more aggressively.
- More technical debt, fewer resources dedicated to supporting existing customers, and therefore, (likely) a team that is burning out creates a potential negative flywheel of increasing customer churn. This exasperates the whole problem.
- This may cause the founders to raise more money to cover the cash flow so that they can invest in making the problem worse by building more connectors. Those connectors represent new market opportunity, and it’s much harder to raise money to “fix the platform” (to bend the cost curve down).
- The metrics — primarily the cash flow — of the business reaches a point where it really isn’t sellable at a premium. The investors can’t earn a return on their investment. The founders can’t run a profitable business. Nobody wins.
This is why iPaaS is hard.
Building an iPaaS almost requires taking on investor dollars.
Running a successful, profitable iPaaS requires the ability to recognize where cost and value of “one more” intersect and the restraint not power past that point.
Those investment dollars change the incentives for the business, obligating it past that intersection point.
Why It Matters
I believe this is important to understand, because thousands of companies and probably millions of users use iPaaS to operate critical parts of their business. iPaaS is often the glue that holds the enterprise together. It creates a platform from a set of disparate systems that would otherwise be difficult to manage.
And, the unit economics of iPaaS mean that the industry is about to go through a phase of creative destruction. I believe we are starting to see this, because I believe many iPaaS vendors are struggling through the challenges I’ve laid out in this post. I believe the current industry is operating in ways that are unsustainable.
That’s important for both the end users of software products and iPaaS products that connect those and the vendors who make those to-be-connected software products. This post is intended to set up future posts about what this means to both of those groups of people. (Follow me to stay tuned.)
This is my perspective about what’s happening in the iPaaS market, but I’d love to hear yours as well! Where do you think I’m right? Where do you think I’m wrong? If you’re in the iPaaS space how has played out (or not) in your business?
