Clouded Judgement 1.16.26 - Platform of Platforms
Every week sI’ll provide updates on the latest trends in cloud software companies. Follow along to stay up to date!
Platform of Platforms
As always, these posts are more of a brain dump of “what I’m thinking” about…And lately I have been thinking a lot about “legacy SaaS",” systems of record, etc. I wanted to write another post today in a similar vein.
When I think about how people and companies interact with software today (and for this post when I say software I’m talking about legacy SaaS systems of record) the pattern is generally pretty simple. The system of record is a single, organized place where a human goes to look something up, understand the state of the world, and then take some sort of action based on the information they gathered from the system of record. Like opening Salesforce to check pipeline before updating a forecast, or pulling up NetSuite to reconcile numbers before approving a close. And more often than not, there are workflows that can be defined and automated around these systems of record - quote-to-cash, opportunity management, rev ops stuff, etc.
One observation I’ve had is that generally the workflows around current systems of record have two properties (not only two, but two stand out to me):
The workflows tend to be a bit more “rigid.” They are very deterministic, and have to follow a certain flow
The workflows can be completed end to end in that one system
As the SaaS market matured, if you wanted to create workflows that spanned multiple SaaS systems, you worked with an IPaaS provider (or other type in integration platform) like a Workato, Mulesoft, Zapier, etc. These were essentially API connections between SaaS applications that enabled bi-directional information sharing (ie read/write). You generally had to define the flow. Define the edge cases, error handling, etc. So there was a level of “rigidity” to them.
When I look at AI agents today - one of the things they do very well is work across systems. They grab information from System A and B, use it to update System C, then create some output or take some action. They’re working across systems and systems of record. That’s usually the work humans did! Humans were the connective tissue between systems of record. They knew where to go, what information to grab, and then what to do with it (and at the same time when to do it). All of that either context or intuitional logic lived in people’s head or some company wiki page. But now, we have agents to do that work.
The key insight for me - agents are working across systems of record. When we ask the question “why can or can’t legacy systems of record just add AI” one important part of the answer is asking the question “well can System of Record A really build a product that works in / on top of other systems?” The existing systems of record work great in their own domain. They have control over their own domain. But as soon as you leave that domain, either their product stops or it doesn’t have access. Agents however are a “layer” that sits on top.
I think this could be a limitation that makes it difficult for legacy SaaS systems of record to build successful AI experiences. Not to say they can’t - some certainly will. But it will be hard. It will require building experiences that span beyond their typical domain expertise. Some structurally may not even be able to.
The user for SaaS was humans - Adding context and providing connective tissue between systems. The users of software in the future will be AI Agents. They will be creating value, taking actions, and defining workflows across systems. The question for legacy SaaS vendors - will they be reduced to a simple store of information for Agents or will they capture the new layer on top? (I wrote about this the other week in my “front door” post, but this is partially what Satya means when he says SaaS will be reduced to a dumb CRUD database). Will the SaaS vendors be reduced as a new abstraction layer enters on top of them? Time will tell!
Top 10 EV / NTM Revenue Multiples
Top 10 Weekly Share Price Movement
Update on Multiples
SaaS businesses are generally valued on a multiple of their revenue - in most cases the projected revenue for the next 12 months. Revenue multiples are a shorthand valuation framework. Given most software companies are not profitable, or not generating meaningful FCF, it’s the only metric to compare the entire industry against. Even a DCF is riddled with long term assumptions. The promise of SaaS is that growth in the early years leads to profits in the mature years. Multiples shown below are calculated by taking the Enterprise Value (market cap + debt - cash) / NTM revenue.
Overall Stats:
Overall Median: 4.4x
Top 5 Median: 19.9x
10Y: 4.2%
Bucketed by Growth. In the buckets below I consider high growth >22% projected NTM growth, mid growth 15%-22% and low growth <15%. I had to adjusted the cut off for “high growth.” If 22% feels a bit arbitrary, it’s because it is…I just picked a cutoff where there were ~10 companies that fit into the high growth bucket so the sample size was more statistically significant
High Growth Median: 12.9x
Mid Growth Median: 7.7x
Low Growth Median: 3.2x
EV / NTM Rev / NTM Growth
The below chart shows the EV / NTM revenue multiple divided by NTM consensus growth expectations. So a company trading at 20x NTM revenue that is projected to grow 100% would be trading at 0.2x. The goal of this graph is to show how relatively cheap / expensive each stock is relative to its growth expectations.
EV / NTM FCF
The line chart shows the median of all companies with a FCF multiple >0x and <100x. I created this subset to show companies where FCF is a relevant valuation metric.
Companies with negative NTM FCF are not listed on the chart
Scatter Plot of EV / NTM Rev Multiple vs NTM Rev Growth
How correlated is growth to valuation multiple?
Operating Metrics
Median NTM growth rate: 12%
Median LTM growth rate: 13%
Median Gross Margin: 76%
Median Operating Margin (1%)
Median FCF Margin: 19%
Median Net Retention: 108%
Median CAC Payback: 36 months
Median S&M % Revenue: 37%
Median R&D % Revenue: 23%
Median G&A % Revenue: 15%
Comps Output
Rule of 40 shows rev growth + FCF margin (both LTM and NTM for growth + margins). FCF calculated as Cash Flow from Operations - Capital Expenditures
GM Adjusted Payback is calculated as: (Previous Q S&M) / (Net New ARR in Q x Gross Margin) x 12. It shows the number of months it takes for a SaaS business to pay back its fully burdened CAC on a gross profit basis. Most public companies don’t report net new ARR, so I’m taking an implied ARR metric (quarterly subscription revenue x 4). Net new ARR is simply the ARR of the current quarter, minus the ARR of the previous quarter. Companies that do not disclose subscription rev have been left out of the analysis and are listed as NA.
Sources used in this post include Bloomberg, Pitchbook and company filings
The information presented in this newsletter is the opinion of the author and does not necessarily reflect the view of any other person or entity, including Altimeter Capital Management, LP (”Altimeter”). The information provided is believed to be from reliable sources but no liability is accepted for any inaccuracies. This is for information purposes and should not be construed as an investment recommendation. Past performance is no guarantee of future performance. Altimeter is an investment adviser registered with the U.S. Securities and Exchange Commission. Registration does not imply a certain level of skill or training. Altimeter and its clients trade in public securities and have made and/or may make investments in or investment decisions relating to the companies referenced herein. The views expressed herein are those of the author and not of Altimeter or its clients, which reserve the right to make investment decisions or engage in trading activity that would be (or could be construed as) consistent and/or inconsistent with the views expressed herein.
This post and the information presented are intended for informational purposes only. The views expressed herein are the author’s alone and do not constitute an offer to sell, or a recommendation to purchase, or a solicitation of an offer to buy, any security, nor a recommendation for any investment product or service. While certain information contained herein has been obtained from sources believed to be reliable, neither the author nor any of his employers or their affiliates have independently verified this information, and its accuracy and completeness cannot be guaranteed. Accordingly, no representation or warranty, express or implied, is made as to, and no reliance should be placed on, the fairness, accuracy, timeliness or completeness of this information. The author and all employers and their affiliated persons assume no liability for this information and no obligation to update the information or analysis contained herein in the future.
SaaS vendors have been building integrations that span platforms for years.
The difference is that AI makes those integrations much easier. Atlassian Rovo for example already has dozens of connectors:
https://www.atlassian.com/software/rovo
If the SaaS vendors execute well, they have the additional advantage of being able to embed those integrations much deeper and more seamlessly into existing workflows.
"The key insight for me - agents are working across systems of record. "
Actually agents have solved this problem and have been doing this for quite some time before AI. Companies like UiPath (or BluePrism, or Automation Anywhere for that matter) pioneered this years ago, so I'm surprised that you mention this as a novel insight.
The only difference is that before a human had to define the flow, and now they are using AI to train the agents. The fact that AI companies are now trying to compete in this space as well would be an obvious next step.
This is the struggle of PAAS companies is that they are all trying to compete in this space, but just like before AI the question is where to invest: in a SAAS's agent and be further tied to that platform (as they'd like it to be sticky), or an independent agent vendor (such as UiPath).