Investor Guide: Forecasting Terminal FCF Margin Of B2B Software Companies (Pt.2)

Summary

• Following on from Part 1, we are going to run Confluent, Atlassian, and SentinelOne through the Terminal Gross Margin Framework.
• We estimate Confluent and SentinelOne will achieve large gross margin expansion over time thanks to their architecture and talent.
• We also discuss Atlassian's prospects of increasing its already impressive gross margin as the vendor increases its revenue from the cloud.

In Part 2 we are going to apply the Terminal Gross Margin Framework we developed in Part 1 to three software companies - Confluent (CFLT), Atlassian (TEAM), and SentinelOne (S).

Recap

As a recap, the framework consists of four factors that influence the terminal gross margin potential of a software company. Those four factors are:

• Marginal costs at max scale
• Talent
• Plans to vertically integrate
• Value proposition potential

We will discuss CFLT, TEAM, and S within each of these four factors and their subfactors, and estimate how they will impact their terminal gross margins.

Marginal Costs at Max Scale

As a reminder, there are four components of marginal costs at max scale: the revenue model, the degree of multitenancy, the amount of information entropy, and the potential breadth of the platform

Revenue Model

CFLT

CFLT was founded by the open-source Apache Kafka creators, to provide a managed service for Kafka. Back in 2014, when CFLT was founded, Kafka was being deployed mostly on-prem and hence the revenue model of CFLT was license-based at the beginning. For on-prem deployments, the license was priced based on the number of nodes, so as per our description in Part 1, CFLT operated a license-based consumption revenue model. This is probably the most profitable type of license-based revenue model for software companies focused on-prem that are reaching scale.

In recent years CFLT has substantially grown revenue from Confluent Cloud, which is its cloud-based platform, representing 46% of CFLT's total revenue in 3Q23. Over time, as more revenue comes from CFLT's SaaS consumption rather than its on-prem license consumption, the vendor's marginal costs will decline. Succinctly, this is because whether the consumption vendor is SaaS or license-based, there are customer onboarding costs, but those costs can be better managed if the vendor controls the deployment environment, which is the case for SaaS but not for license. Furthermore, SaaS-based consumption is more granular, meaning CFLT charges based on data transfers and the number of tasks completed per hour, which is highly aligned with the true usage of the customer. This better alignment fosters greater scalability for CFLT and its customers, leading to lower marginal costs.

On the whole, CFLT's mix shift to greater revenue percentages coming from the cloud means that investors should expect its marginal costs to reduce as it reaches max scale, supportive for higher terminal gross margins.

TEAM

One way that TEAM categorizes its revenue streams is via its deployments - cloud, data center, server, and marketplace & services. Data center and server revenue segments are from on-prem license-based deployments, the former targeting larger enterprises and the latter serving SMBs. Cloud and data center revenues have grown substantially in recent years. Cloud represented 46%, 54%, and 59% of total revenue in FY21, FY22, and FY23, and data center represented 16%, 20%, and 23%. TEAM's on-prem licenses and SaaS are priced on a seat, or per user, basis.

In Part 1 we discussed how the marginal costs of a license-based vendor are subject to the level of involvement required during installation. There are a number of on-prem vendors, such as SAP, Oracle, IBM, and VMware, that provide direct support during the deployment, and this is likely due to the complex nature of their solutions. However, TEAM adopts a less hands-on approach and instead provides extensive documentation publicly available for customer's IT teams and third-party solution partners to learn about the installation and do it themselves. With that, given TEAM's marginal costs may already be relatively low for its licensed on-prem business, transitioning more revenue to SaaS may not yield meaningfully lower marginal costs.

Interestingly, this isn't the case for CFLT's on-prem business because generally those IT professionals attracted to open-source projects like Kafka have a higher degree of technical self-sufficiency, meaning they don't need third-party solution partners to do the basics, but they do need CFLT's managed services for complex customizations and the ongoing operations.

S

S' revenue model is 100% SaaS-based. The vendor prices Singularity bundles (including protection for identities, endpoints, and the cloud) on a per-endpoint basis. This is similar to the per-user or per-seat model, which, as per our Part 1 discussion, is a model with lower marginal costs and higher gross margin potential than the consumption-based SaaS alternative.

Within the bundles S includes a period of data retention for the telemetry collated from customers' endpoint protection and cloud operations, and customers who require longer data retention pay more accordingly. So, in effect, S' revenue model is mostly per endpoint, but there is a considerable consumption component associated with the amount of data stored.

Those SaaS vendors who price per seat or user are able to do so because there is not a huge difference between an average user and a power user. For example, there is unlikely to be large differences in compute, storage, and networking costs across users of CRMs (Salesforce, HubSpot), productivity platforms (Monday, Asana), and collaboration tools (Microsoft). Sectors like these often show reduced and consistent resource usage, which can be reliably forecasted. Consequently, it's feasible for SaaS providers to implement a pricing strategy based on user count.

The same considerations apply when pricing per endpoint but with some nuances between client and server endpoints. Most endpoints are client machines used by employees and they tend to have very persistent logging patterns, meaning that the difference between an average and power user is relatively small. Hence S can use the average amount of telemetry generated by a single client endpoint to operate a price per endpoint revenue model. Server endpoints run orders of magnitude more workloads, and handle sensitive data and critical tasks, therefore, S prices the endpoint protection for these agents at a much higher level versus client endpoint protection.

The per seat/user/endpoint SaaS model is highly lucrative when a vendor optimizes their architecture and prices their services correctly. S is certainly one of these vendors and hence their revenue model will support lower marginal costs and higher potential gross margins as the vendor approaches max scale.

Degree of Multitenancy

CFLT

CFLT has added significant multitenancy to deliver multifold greater scalability and cost effectiveness for customers. Kafka is a VM hosted architecture which inherently delivers lower resource utilization than more modern container-based architectures. CFLT provides a managed service for Kafka, originally working with the VM-based architecture, but in recent years the vendor has infused process-level multitenancy via the use of container knowhow, delivering far better TCO for customers compared to them using Kafka in a Do-It-Yourself fashion.

Furthermore, Kafka couples together compute and storage, which leads to further poor resource utilization and higher costs. CFLT addresses this in its managed service by separating compute and storage, enabling customers to greatly lower down their costs while providing greater scalability. In essence, CFLT's biggest change is that they have moved away from VM-based clusters to a complete serverless architecture with compute and storage separated, providing Kafka users with a very high degree of multitenancy and scalability.