For context on the theory behind this, please see the original article. The original ShitCo index was created on the premise that there is outsized returns in a collection of left for dead but potentially disruptive companies despite mortality rates. That’s been proven true - since the index was created, returns have more than doubled the NASDAQ.

Based on my view of software and what i’ve written about in the last few posts, you may wonder why I didnt create one during the period of SaaS destruction. The reason is simple - it was a valuation disconnect and for the majority of SaaS companies, there was a natural bound on growth after which it begins to flatline.

For this index, i have included select software companies that are seen as permenantly impaired which to me is a better representation of the goal.

I’ve bucketed these into a few different categories:

• Chinese Robo theme: ADR was a prereq to make this more accessible to people. The aggregate value of these 4 companies is only $15B and one of the company’s primary business is making cars. In contrast, in the U.S. private robotic companies have raised in excess of this amount in the last 6 quarters alone with several exceeding $10B in private valuation (e.g. Figure, Skild)

• Under-monetized US internet: Dating, niche social properties and now Trade Desk have been uninvestable in recent years. I don’t necessarily have an answer to how to increase monetization but the audience being commanded and the optionality if operational streamlining qualifies them for inclusion

• Left for dead software: Well..this speaks for itself. Anyone got a smart investment case for Docusign or ZoomInfo these days?

• Consulting: Conceptually this is a bet that consulting could one day become a huge beneficiary of AI due to the shortage of qualified labor to help implement in the enterprise. This has yet to happen but you can see the investments being made into this area by OpenAI and Anthropic to validate that the demand certainly exists.

Full list below, i’ll track these periodically.

Disclaimer: I hope this goes without saying considering its called a ShitCo index that this is not investment advice. #s are capiq/factset so may contain errors.

What is “Enterprise Software”

The terms Enterprise software, B2B, the flashy powerpoints and evangelical speeches given by executives have glamourized this industry so much that we forget how mundane this entire industry really is. The entire point of existence of business software is to allow employees to work in a more productive way. That can range from putting a customer record in a place, a support ticket routed from a queue to a person, a doctor pushing a button to send a prescription to a pharmacy or a system administrator seeing utilization of servers across all its infrastructures. There isn’t one industry or type of company, but the entire global GDP and thousands and thousands of different industries. The key point here is that if you add up all the business processes, workflows and requirements, the number will be in the millions if not billions.

A million little steps, captured over decades by thousands of companies and designed by different companies and delivered to the user through a computer workstation or on a browser.

The Parallel for AI…India and China

Business software as an industry is small in China and India because labor is a direct competitor to packaged software. Historically in these lower cost labor markets with exceptional technical talent, DIY has been the go to solution. Most western company leaders would be shocked to find that technically savvy Asian tech companies not only are able to in-house their own business applications, but even databases, BI and infrastructure technology.

Is this the direction the world is headed? When the token costs decreases 100x, its tempting to think that the math becomes:

Token to generate code + 2 SWE < annual cost of CRM license

But in reality, the decision is a trade-off of management bandwidth. If a vendor CRM breaks, a customer can expect a SLA for it to be brought back up. If there is a security vulnerability, thats the vendor’s responsibility. In fact, the extreme examples of DYI are only found in the most sophisticated technology companies in Asia. I fully expect AI Labs to experiment with DIY everything but with IT at ~5% of US GDP, I would consider this an edge case.

Attempting to get in the heads of AI Labs

When I try to think about the how AI Labs think about the grand strategy, there are 3 pillars of their vision

• Win consumer usage

• Win enterprise usage

• Win the ecosystem

Somewhere between the 2nd two bullet points comes an intersection. AI Labs’ primary focus today is to maintain leadership in the frontier which is a game of compute (a lot of compute). To win enterprise adoption requires two things: (1) the best model and (2) companies to use these models in a way that drives value. Today the GTM is very nascent - companies (not individual developers) can buy from a AI Lab by either accessing the model through APIs or buy one specific application such as an enterprise grade chat. When big opportunities come along, AI Labs need to dedicate resources to life sciences companies, large retails, healthcare institutions to forward deploy headcount to help productize the vision. This is a labor and cost intensive exercise that cannot scale. As a result, the more scalable model today looks something like an OpenAI frontier - instead of selling tools (e.g. API), AI labs are selling agent solutions and scaling their deployment team and supplementing with partner training such as BCG and Accenture. Classic software playbook.

The other way AI Labs will make more money in tokens is by enabling software companies the same agentic capabilities to ultimately present to its end customers. Afterall software companies employ the most high caliber engineers and are in a better position than the end customer. Ultimately an AI Lab doesn’t care how a token gets consume - whether directly by the end customer or through a software partner/customer.

I think the barrier to agentic success today is primarily because companies simply dont know how to implement the tools available. This is an area where AI Labs will find collaboration with traditional software businesses to be in their best interest.

This is a long way of saying AI Labs will be selective about which first party applications they themselves will go build. But they have a distinct advantage in that know the billions of questions being prompted each day. Personal health, personal finance, coding, improving writing skills/education, etc. are on the top of that list. And I were to bet, the focus of first party apps will be in these areas.

…But Agents will do it all

I very much enjoyed reading Citrini’s write-up but the one detail that he didn’t mention is where these ubiquitous agents come from. There’s several possibilities.

a. AI Labs will have unlimited capital and will identify every large TAM and create a competitive solution, hire tens of thousands of sales reps, solution consultants and tier 2/3 support employees. In this case, all money flows to AI Labs. However, this would be similar to saying NVDA and AMD should displace all hyperscalers by launching their own hosting service. Its possible, but the trade-offs are not worth it at this point in time.

b. Agents are so easy to deploy and manage that customers will simply all deploy everything themselves. Money flows to AI Labs and in theory aggregate industry margins go up because money is saved

c. Ease of code generation makes each category of business software so easy to create that it attracts a new wave of companies and VC funding thereby driving down prices for incumbents. Whether thats a new interface paradigm or just better and more automated software. Basically a supercharged version of how AWS made computing accessible. Very possible scenario but I’d want to acknowledge the strange loop logic of why VCs would are about business software as a category if it becomes this commoditized

d. Incumbents adapt. For some reason, companies that exist in the public markets get no zero credit for their ability to adapt to change. The narrative has become binary - Claude code can do it, hence X and Y companies are dead.

I think the reality will settle between c and d. Yes agents will be transformational, but i’d bet a good portion of the agents will come from the boring old companies you already know today

Oh wait, there’s more than a business process than code

The reality of a regulated industry is that the value proposition is the sheer volume of dirty work that needs to be done in the background to present a customer with something simple. While it may be true that a payment portal can be generated in hours vs. months now, the moat of a payment company is dealing obtaining bank licenses, putting in place a AML/KYC program with the adequate controls for SARs and fraud detection (just ask CZ at Binance). Same can be said healthcare, telcos and a variety of industries. Not only is there no value for DIY, the risk of doing so far outweighs the reward.

What now and what it means for valuation?

Several things can be true at once:

• Software companies need to be able to adapt, and some will do it exceptionally well while others won’t

• New companies will be created

• Pricing may be compressed

• Most software companies are too bloated

At the end of the day, what the capital market is doing is applying a higher discount rate to the interim 10 year likelihood of previously forecasted cash flows and the terminal value after those 10 years.

My personal tactical take:

• Markets are over discounting the next 5 years by at least 25%

• Not enough credit for SaaS to grow FCF faster, even if topline slows down further

• Narrative sell-off in areas that will see tailwinds from pure traffic consumption (particularly in network security)

Take a standalone business like OpenAI as an example, today there are generally two core revenue streams:

• API Access

• Seats (e.g. ChatGPT monthly fees / Enterprise negotiated fees)

Underlying both are the significant costs of training and inferencing. However, there is an important distinction for training cost. There is the training/inference cost that directly supports the revenue generating business and the “discretionary” training cost to sustain a lead in cutting edge research.

Estimating Unit Economics of API

Let's work backwards from COGS. I believe the lowest per GPU hour cost for H100 cited in the market is in the ballpark of 2.60-2.70 and lets suppose the blended average is 3.00. However, API fees are usually priced on a per million token basis for input and output. For example, a newer model for text charges $2/million tokens for input and $8/million tokens output. To translate them into the same metric:

Based on the estimate, at worst the API business is a breakeven business, but more realistically the unit margins are in the 40% range. As new models are introduced, the API customer cost from old APIs drop significantly. However, compute will continue to decrease and computing power will also continue to multiple.

Estimating Unit Economics of Seats

Paid seats is the high gross margin business for GenAI as illustrated below. But keep in mind the paid portion of user base is likely 10% of total users so there will be a cost to serve free users. However, given caps and lack of access to frontier models, the cost to serve a free user will be lower. I have assumed its half for simplicity. I think it would be reasonable to conclude that paid user base would be closer to 80-90% gross margin and on a blended basis margins in the 40s-50s.

Mix and “Extra Compute”

Based on what’s publicly available, my assumption is that the majority of revenue for a business like OpenAI is seats and a growing portion is API and other innovations.

If the goal of a scaled GenAI business is to scale to $100B scale, I think its highly achievable that gross margin scales to ~60%.

The wildcard that is hard for an outside observer to pinpoint is how much additional compute is desired/needed to be sustain model leadership. I suspect the answer today is “alot”. However, as with any innovation, there will be aspects of model development that becomes socialized.

Take-away and Implications

My takeaway is that a leading GenAI business at scale can demonstrate respectable unit economics and that the burn rate is likely much lower than outsider think. Whether or not each individual company incurs incremental “compute burn” is at their own discretion on how they think about the future.

When you factor in macro industry trends given we are still in the very early innings of AI, I am not surprised by the investor appetite to invest in leading models. The questions how many companies are capable of executing at the scale of OpenAI. I suspect the answer will be very few.

My negative read-through is Nvidia. For the AI companies to succeed in the future, cost of compute MUST come down. This is true for almost any industry and I can’t imagine its not true here. As a greater portion of cost becomes inferencing, Nvidia has to either drastically increase density, lower price or be partially replaced by competitors.

First a few definitions:

Bookings: The value of customer contracts signed in a given period

Billings: The value of customer invoices in a given period

Deferred Revenue: A balance sheet liability created the customer is invoiced but services are not yet delivered

Remaining Performance Obligation (RPO): Essentially a superset of deferred revenue plus all the binding contractual customer commits you have signed but not billed or invoiced

Capitalized Software: Normally when you think of R&D, it’s an income statement expense. But some companies will “capitalize” a portion of that R&D expense, which is to say they put it on the balance sheet as an asset then amortize it over time (usually 2-5 years). There are GAAP principals to allow for it in some stages of development. The issue it creates for investors is that it makes comparisons more challenging across peers often we “reverse” the capitalization for apples to apples comparison.

Go-live and Provisioning: Go-live is the “launch” moment when the system is deployed in a live production environment, users have access, required data is migrated, support desk is in place to help resolve issues and tools are deployed to monitor operational health. In contrast, Provisioning is when the vendor has delivered access to the system based on contract terms (e.g. tenancy and accounts are set up, 3rd party integrations required are done) but there other steps that may be needed for go-live to occur. Different types of contracts will differ when revenue recognition starts but its not hard to see that SW vendors will push as much as their obligation to end at provisioning in order to achieve faster rev rec.

Seasonality

Yes, certain industries will always be subject to seasonality and seasonal budgets (e.g. marketing budgets, retail budgets). But by and large, software is driven by fiscal quarter end incentives. Whether Q4 is in December or April isn’t as important (generally speaking) than the sales incentives put in place to drive behavior such as allowing reps more discounting in certain quarters.

Sales Roles

Before getting into ARR and revenue, it's good to understand typical sales roles within a cookie cutter software business. As talked about in part 2, this is the single biggest toggle a company has to make changes. As an investor (as opposed to an operator), this isn’t meant to be a deep dive of sales ops efficiency.

The machinery starts with trying to figure out the right number of reps relative to demand. Too many reps, spend is too high and productivity is too low. Too few reps, opportunities are not adequately covered.

Reps: Carry a quota, on-target earnings (OTE) is levered towards commissions. A person who is capable of being trained on how to position a product and move deals along the various sales stages to closing.

Pre-sales (Sometimes called a sales engineer): This is a critical role in that the rep is just a account manager, the pre-sales team is the ones who actually understands the product and how to demo. Typically speaking, once a deal is qualified, a rep will bring in a pre-sales person to lead the next level technical discussion. Usually paid in some form of a pooled bonus.

Customer Success Manager (CSM): After an account is won, the CSM takes over the account and is responsible for that account, including renewal and CSAT. Sometimes the job of upselling to that customer gets moved over to the CSM org, sometimes it stays with the reps. Comp has elements of commissions, particularly tied to renewals but not as levered as a rep.

Business Develop Rep (BDR): More often than not, when you see a tiktok video of a tech sales bro out of college, that’s a BDR. Entry level role, responsible for generating leads that get handed off to a rep. Total comp is lower and good performers can graduate to a rep as a career path.

Sales ops and support: Wide gamut of indirect revenue generating roles such as alliances and partnerships, to sales support functions like operations, comp and commission planning or sales finance or deal desk. The back-office of sales.

Managers: Everything from a CRO down to managers of individual sales functions. Leadership is important but these roles arent meant to be directly closing day to day deals as their success is tied to the “roll-up” numbers of the entire team.

This is just one of many examples of how you might measure the sales organization with target ratios tied to number of reps to arrive at an all-in expense/rep.

New Bookings

There’s no shortage of ways you can build a few hundred rows to get to total bookings but its usually a combination of capacity based (how many reps can we onboard) or demand based (how many deals to close a quarter).

Quota setting, commission setting are fairly complex activities but for modeling purposes suffice to say that a fully ramped rep will be much more productive than a new hire that usually has 6-9 months grace period to learn before being required to make some level of quota.

You can triangulate the numbers of deals you need, or in the reverse. End of the day its more an art than a science. As a public market investor, this is more about understanding the factory line because in reality, you do not have access to this level of information.

In businesses with usage/consumption pricing, the model without customer committed spend becomes less predictable outside of the base platforms fees. Typically it involves a level forecasting with the customer and a heavy portion of the reps commission is then tied to customer consumption to align incentives.

Bookings to Revenue (Basic Concept)

At a most basic level, in a contracted model (e.g. fixed price seats), rev rec is fairly simple. You book a 3 year deal, you recognize ratably over 3 years. The thing to note here is that it’s common to assume deal activity is quarter back-ended loaded in that a large volume of deals each quarter for an SaaS business selling to large enterprises are closed in the last week of the quarter so its typically a good practice to lag by 1 quarter. Selling to SMB will have much lower backend loading effects.

Renewals and NDR

Renewals are easy to understand on the surface but because the entire software industrial complex relies on renewals to survive, its actually become rather complicated.

At the most basic level, in the example above, a customer has signed a binding agreement to pay you for 3 years for the service. Outside of situations such as ‘termination for convenience,” where a customer has the ability to send notice to terminate within the term, this is “locked in".” At the end of 3 years, the customer can choose to renew or cancel.

During these 3 years, the software company’s job is to get the customer to spend more. Maybe the customer grew in size or added employees, or maybe they’ll buy another product. Equally likely is the reverse causing downsizing in seats or divisions. So the concept of “Net Dollar Retention” is simple: to measure beginning period spend vs. ending period spend. If the numbers are equal, you have 100% NDR. Simple enough right?

Unfortunately, through business model evolution and craftiness, I can think off the top of my head at least 6 ways NDR is measured (I believe the actual variety is 11). For example:

• Companies selling to SMBs often use monthly recurring revenue (MRR) to calculate because their contracts are month to month

• Some will exclude foreign exchange fluctuations

• Some report metrics for only certain cohorts of customers

• Some will only report Gross Dollar Retention (showing only churn and downsell)

• Some include usage from customer cohorts which can show significant fluctuation

• Some don’t consistency disclose when the company is large enough (e.g. salesforce)

If we continue with the same numerical example, a simple revenue recognition schedule would look like this assuming that initial booking got renewed at 90% 3 years later:

Its important to draw the distinction with ANNUAL renewal rate vs. AVAILABLE TO RENEW (ATR). Available to renew is the measurement of actual renewals against the pool of contracts that are actually up for renewal. The numerical difference is significant, and since publicly available disclosure is focused on annualized renewal rate, its important to draw this distinction.

Quick Note on Consumption Ramp

It may be obvious but I continue to be surprised when I see models that assumes consumption ramp being modeled like seats (sign a deal, start to ramp in a quarter). Generally the larger the deal, the longer the ramp period. Take a AI model training on a hyperscaler use case:

• A medium size AI workload likely takes 9-12 months to fully ramp. 1-2 months of provisioning, VPC setups, 2-3 months of migration planning then a gradual migration of workloads on the new cloud.

• A large AI workload can be 2 years or longer. Oftentimes these deals are contracted based on a delivery timeline estimates of a datacenter location being ready (power availability), then GPU delivery milestones to follow. So the booking (and RPO recording) happens before a site may even be built which creates a lot of wait and see for investors.

Professional Services Revenue

We generally think of PS effort as a function of product revenue. When PS requirement is low (as in SMB), the product is generally more standardized. When PS is high (like large ERP, banking or regulated industry), the product is usually heavily customized. The modeling intuition is not difficult to understand and is more of a function of headcount to scale. Services work are usually priced in 2 ways: (1) Time and Materials by the day or hour or (2) Fixed Priced, either in a statement or work or as a price list SKU. As an aside, there are Indian BPOs who are extremely profitable on professional services because they are able to hire in Indian markets then bill in US rates. Margin is a function of labor utilization and cost relative to pricing of the services work to customers.

Cost and Opex

Outside of the Sales cost, other cost items are not really worth a detailed discussion.

• Cost of subscription generally include: Cost of hosting, support team, operations team managing the environment, the cost of 3rd party licenses used in the product

• Cost of services is the headcount cost supporting PS work

• R&D is primarily headcount between developers, QA, product management plus tooling and test environments. Its more art than science to gauge R&D efficiency because its predicated on the notion that you are building a product that will have broad customer appeal, and the ability of the team to iterate to change.

• Sales is majority headcount and commissions

• Marketing is a combination of events, analyst relations, brand marketing, ads and sponsorships

• G&A are the backoffice functions

• Its worth noting that most software company cost line items are fairly uniform and that all line item costs are typically fully burdened. Meaning, the rent, benefits, IT, overhead are loaded into the individual line items as opposed to sitting in G&A

Here’s an example of a mature company income statement (CRM)

Working Capital

Putting this all together, if you assume the same $22.5M ARR deal with billing terms of annual billing up-front for a deal signed on January 1.

As you can see, as deferred revenue liability increases on the balance sheet, it is a source of cash.

Final (reluctant) Words on Stock-Based Compensation

When software investors talking about margins, we are usually talking about non-GAAP margins which excludes intangible amortization (M&A purchase accounting), 1x costs and stock-based compensation.

SBC in theory capture several types of securities, but in practice, majority of publicly traded companies have moved to RSUs for broad base employees, with options/PSU reserved for leadership

• Restricted Stock Units (RSU): Employees get set number of shares that vest over a period of time.

• Options: Contracts that let employees buy company stock in the future at a fixed price (strike price). By the time you vest, if the stock is below your strike price, that option is underwater. If it is above the strike price, you can cashless exercise for the net proceeds.

• Performance Stock Units (PSU): Similar to RSUs but typically reserved for management. Instead of a time-based component, vesting typically depends on hitting a set of stock price return + financial metrics.

SBCs are excluded for non-GAAP measurement for a few reasons:

• It’s non-cash

• Timing of grants could create sizable volatility in the income statement

• SBC is expensed over the grant period (service period) but employees who leave and terminated will lose the unvested amounts

Whenever the market is down, we will hear a few months of lobbying against SBC add-backs. But rather than let my bias influence you, here are the classic pros and cons argument against SBC:

Model of SBC:

Using an example of a company with a stock price of $100 with 10% annual appreciation, 100 employees who are paid in $100k salary and $30k a year in RSU. RSU vests over 4 years in equal annual installments.

Details

If there are specific topics that could use more details, please let me know!

The Old Revenue Model

Back in the old days when dinosaurs roamed the earth and Wall Street carried Blackberries, enterprise software was largely very uniform.

Company A charges company B a perpetual license to its software. What this means is the licensee paid a 1x fee to use the software forever (not the ownership the IP). The license is priced on some logical metric that aligned to scope (# of seats, # of devices, etc.) Then in order to receive updates, patches and bug fixes, Company A will change company B a support and maintenance fee usually equal to 20-22% of the value of license every year. In consumer software, think about the old Microsoft office disk - you bought it in a store and you owned it. In enterprise setting, what typically happened was the vendor established a very high list price for the software, then in sales cycles, licenses usually got discounted up to 80% to get to a street value. Then it made even more money by implementing the software - using either its own consultants (or 3rd party consultants known as system integrator like Accenture) to help customers configure, set up and get the system up and running. Often, the price of this service was can be 3x the amount of the license. So in numbers, the revenue model usually looked like this:

Cash flow more or less mirrored the revenue schedule since licenses were recognized up-front and paid. From a public market perspective, we focused on license revenue every quarter since that is the fundamental driver of the business. As you’d expect, there was a lot of lumpiness on license but supported by a generally stable stream of “insurance” for support fees.

Early Day of SaaS

Fast Forward to early 2000s, Marc Benioff came and said the traditional software model is broken, it created a mis-alignment of incentives between the vendor and the customer. The vendor’s objective is to maximize the value of the up-front license, and what happens afterwards was the customers problem. Instead software should be a service, where the economics of the deal was spread out over time so that if the vendor wasn’t continuously adding value, it would lose money when the customer cancelled early. AND, software is available on any browser and you got updates when you logged in!

To spare you too much history, Salesforce, Workday and Netsuite, as early leaders in the new Software-as-a-service (SaaS) model, changed the economics of the industry and the model began to look a lot more like this:

The traditional software business model is predicated on the idea that you hired a group of engineers (fixed cost) to build a product and sell infinite numbers of times at minimal variable cost (commissions). The arrival of SaaS has changed the economics as every incremental deployment cost more data center compute and required continuous improvements to retain customers.

In the old license world, a customer bought a license and installed the software in its own datacenter. In the SaaS world, the vendor ran the software in the vendor datacenter so gross margins were lower. Early SaaS also tended to be much more out of the box and customizable so service requirements were generally lower. The biggest advantage was because there is a continuous dialogue between the customer and vendor, when the vendor came up with an another product, there was a very logical conversation to upsell.

From a public company perspective, you have a highly predictable recurring stream of revenue that in theory would accelerate if you continue to grow new business without losing existing business. However, the model is more more opaque in some ways:

• Bookings (value of the contract signed in a qtr) is the forward indicator instead of license revenue. There are two types of bookings: New sale and expansion sale into an existing customer which could be selling more volume or another product (together, net new business) and renewals. Not only did companies not often disclose bookings, you wouldn’t be able to decipher new vs. renewals. Even if they provided bookings, it was unclear if you are comparing apples to apples year over year because some contracts can be 3 years and some longer or shorter.

• Cash flow:

  • When you sold an up-front license, the fees are typically collected soon after signing. The value of the annual support fee is first put on the balance sheet as deferred revenue (its a liability of something you billed a customer for but haven’t delivered) then it burns off as revenue as you deliver the services with the passage of time.

  • In SaaS, there’s just a lot of variability. Say you sold a 3 year deal, sometimes a vendor will offer attractive discounts to customers to pay all 3 years up-front to help with cash flow, sometimes not. But the general rule of thumb is that the cash flow characteristics will look better than the income statement suggests. Invoiced but not performed portion of the contract becomes deferred, then recognized as services are performed (time).

Term License / Subscription License

If you want to be pedantic about it, SaaS by definition is a service where the application, hosting and support are grouped together into one element. So in that sense, it should be vendor hosted and sold as a “turnkey” solution to the customer to be SaaS. For new startups, that is usually the de facto founding model. But what about all the old companies that coudnt’t re-architect fast enough but also want a “SaaS multiple” or companies selling into regulated markets where customers have to host the application in their own datacenter for compliance reasons? Enter “Subscription licenses” which even today is very popular in private equity land.

What typically happened was you had effectively an on-premise application architecture, but instead of charging customers a 1x license, you mirrored the SaaS model by bundling license and support together and spread out the payment over multiple years and provided the customer the license right to use during that term. A customer can then decide to self-host or the vendor may take effectively an on-premise application and host it for them for a separate fee. The accounting for these licenses are much more complex. In some cases, certain duration of term are required to be recognized up-front as perpetual license and in some cases the support and license values are required to be carved-out separately. Suffice to say, financially this made many traditional software businesses look like SaaS without having to make the necessary R&D requirements.

Cloud Today and the Rise of Consumption Model

Fast forward to today, Cloud business model has advanced significantly but generally speaking, we have 4 flavors:

1. Traditional seat/metric licenses: There’s a set value for bookings and recognized ratably monthly over the contract term (e.g. Workday selling a HCM seat, or Gitlab charge by user per month). This is predictable to forecast.

2. Consumption model: This is the de-facto consumption model in most infrastructure software where the idea is the customer pays for what it consumes. For example, when you sign up for AWS online, you pay for their computers on a CPU/hour basis, you use x hours, you pay x hours. Same for for a virtual firewall where you are paying based on throughput. This is much harder to forecast because you are relying on the customer’s consumption forecast and how fast they can begin consuming depends on how fast you can get them up and running. More often than not, this is paired with a baseline predictable platform fee. Take Bill.com as an example, they will charge you a base fee to use their software + take a cut of payment volume.

3. Committed model: Similar to consumption except the customer is committing to an annual or multi-year spend. This allows the customer to obtain better pricing and the vendor to recognize bookings. For example, if customer A committed to spend $100M over 4 years, at the end of 4 years the actual usage will be trued up (or if the usage is less than $100M, customer still pays). The bigger the company gets, the more creative it can be with a commit model. For example, Microsoft would be able to go to a large customer and say - if you commit to spend $1B a year with us, you can use that pool of funds for any products. This type of customer control suddenly makes competition really difficult for best of breed point solutions. A customer may want Slack, but have a pool of money to spend with Microsoft, maybe Teams is good enough.

4. Developer centric / product led models: This is similar to consumer services where the selling motion is more akin to a freemium model that incentivizes immediate usage by a developer for free (with caps based on some metrics), then a per user per month fee to gain more features or caps, then an enterprise price that usually requires speaking to the sales team.

Go-to-market and selling model

The software go-to-market model is a complex topic. Without getting into all the nuances (Dave Kellogg has great articles about software GTM if interested), lets focus on the overview of the model:

In the on-premise / license sales days, a typical enterprise sales org had a head of sales who was in charge of selling license, a head of services who was in charge of selling and delivering services and a head of support. This model had many benefits but also 2 key draw backs in a customer centric world - (1) the responsibility for the customer experience sat with 3 people and (2) the sales guy was motivated to sell license and the service guy was motivated to maximize PS which often is at odds with what’s best for the customer.

Enter the Chief Revenue Officer role. Today’s SaaS sales organization largely places the customer in the middle with a CRO responsible for the majority of GTM functions. For the most part, PS is viewed as a enabler for product success and the sales org usually has one of two flavors: (1) Pure territory based, each rep gets a number of zip codes and is responsible for accounts in the territory (sometimes its by industry) or (2) sales is focused on selling to new customers and a customer success org is focused on “farming” or upselling new modules to existing customers.

Marketing plays wildly differently role within different types of businesses. The term you typically hear is corporate marketing vs. field marketing. Corporate marketing is branding, AR, etc and field marketing is tied to specific events and campaigns support the sales effort. Suffice to say that the closer a vendor is to the end customer the more reliance there is on field marketing activities to generate leads.

The typical forecasting model for a software business has 7 stages:

Lead => Qualified Leads => Lead nurturing (demos, meetings) => Proposal => Contracting => Closed/Won =>Renewal upcoming

so the new bookings model is actually quite simple:

Budgeted # of reps x full quota per rep = total booking capacity

Actual # of reps x actual quota attained per rep = actual bookings

A general rule of thumb is to think of raw pipeline to bookings as having a 3x coverage

Sales Efficiency

Efficiency is big topic in software investing because the relationship between customer revenue coming in and the cost to acquire the revenue is the single biggest driver of profitable growth. In early stage investing, the metric you are taught to focus on is the lifetime value of the customer relative to the cost to acquire that customer. I don’t find that to be particularly helpful in later stage or public investing. What I’m focused on is whether there’s natural growth in the market for your product? The biggest pitfall companies and investors fall into is this idea that growth is capacity constrained by the number of reps, so let’s go hire more reps and more revenue will show up! But that’s not always the case of course. In an ideal world (say you are a PE doing diligent with full information under NDA), you'd be able to see rep level attainment, measured against new and expansion ACV. In public markets you almost never have that level of detail, a back of the envelope math for me is looking at the yoy change in revenue relative to the total S&M cost expensed. You get a pretty interesting look at which companies have demand for its products and which ones do not.

The Analytical Framework

Some may disagree but to me the most important thing to remember is you are trying to make an investment, not purchase the technology. While having a strong technical background helps, particularly in early stage software investments, by the time a software company goes public, you are usually NOT taking technology risk. The risk you are taking is (1) Team has a firm grasp of what is happening in the market and can evolve with urgency (add new products, adjust sales velocity, make customers happy) and (2) Overpaying for a perceived trajectory that isn’t true (think Zoom growing another 30% yoy after COVID). keep in mind, as an minority investor, THE ONLY CONTROL YOU HAVE IS THE PRICE YOU PAY.

Levers

Ultimately you can make life a lot easier for yourself if you keep in mind that most software businesses are not that complex, the levers to pull are limited to:

• You can ramp up and down quota carrying reps

• You can change the quota structure and commissions to drive different behavior

• You can focus on retaining existing customers and selling more to them vs. going after net new

• You can increase or decrease R&D spend to bring forward of scrap roadmap products

• You can be creative about how you license your product to customers

The end goal of cloud software businesses is a model where gross margin approaches 80% and operating margin approaches 35%, hopefully while growing topline continuously. In reality, this has rarely ever been the case. The natural tension is sacrificing margins to keep growing vs. profitability. The public market plays a large role in this pendulum in how we reward companies for growth (until we don’t).

Part 1 covers the basics primer from a practical perspective.

Part 2 will focus on the business model of software.

Part 3 the financial model mechanics and nuances.

None of these are absolutes but thought it would be interesting to share some of the taxonomy and modeling nuances we use to train generalists. I’m sure many of you can build more elegant models than me but the idea here is the principle of why you do certain things vs. the mechanics. I want to do this in a way that uses simple words to describe things vs. the jargons you see in most places that likely means nothing to most generalists.

First, let me assure you that enterprise software is extremely boring even though the ecosystem and buzz might seem splashy and sexy.

There’s this thing called a “cloud.” This basically means you have a giant warehouse called a datacenter. In this datacenter are rooms called data halls with racks and racks of computers (servers) connected to power. Some of these servers power general purpose workloads (CPUs) and some of these servers power very specialized workloads like AI (GPUs). Then these computers allow for applications to share computing resources and you can access them through the internet.

In enterprise software, there’s really 3 basic “stacks”

• The applications that you use. People generally separate them into two categories: “horizontal” means financial ledger or a HR system that any industry can use. “Vertical” are systems specific to an industry such as software that lets a telco bill its customers, or a set of programs that allow banks to offer you online banking. Within horizontal, there are essentially two broad categories - back-office which are the HR, tax, finance, supply chain functions that are very important for large businesses and front-office - which are the customer facing software such as programs that let a sales rep type in a prospect (CRM) or a set of kits to let you build a website or storefront.

• “Infrastructure” software is essentially the plumbing to allow systems to function well. There are alot more things in this part of the world such as an operating system or a software that helps different programs talk to each other and handle requests and deliver to the right place (called middleware and web servers), but for purposes of public market investors, there aren’t enough here these days to really call out separately.

• Hardware or “Metal”. which is the actual physical machines that are sitting in a datacenter such as servers, storage boxes or network appliances. Oftentimes, these hardware devices are “virtualized” which just means it allows a machine to carve out resources so it looks like separate machines from a resource perspective.

So the next time you hear AWS - what is it exactly?

For the most part it is taking all these servers and storage boxes that it has sitting in a datacenter and renting it to customers by the hour and it makes a good margin doing it. Beyond that, AWS will offer you many many higher level services such as database, monitoring, and countless other things to you.

In the old days, a company would need to rent a datacenter space (from a colocation provider like Equinix), figure out your own datacenter design and rack your own servers. If you were starting a business today, the vast majority will choose to leverage a public cloud such as AWS, Azure, GCP or OCI which has done all the work for you. But it’s worth noting that despite the sheer size of these hyperscaler cloud providers today, the vast majority of large enterprise IT is still self managed. A bank is not ready yet to simply turn over their entire business to a 3rd party.

A small history tangent

The majority of the software companies that still exist today (and some are even thriving) from the last era tend to be companies who supplied plumbing to help large enterprises architect their datacenter. Companies like Teradata and Oracle remain the database backbone of the majority of Fortune 500 especially in regulated industries like banks, telcos, insurance, utilities. A key reason is volume of data + integrity of data + language dialects to translate schema. Contrast this with application companies of the last era (Peoplesoft, Siebel, Baan, JD Edwards, etc.) are either dead or consolidated.

Terms you hear often and what they mean

Workflow: Like the name implies, traditional applications basically map out a series of steps or actions based on the underlying work. For example, recruiting software will have a series of steps and sequences to follow from candidate identification down to onboarding. Workflows are usually out of the box with rules and configurations that every customer can make.

System of record (SoR): This is a single source of truth about a specific type of information. In any large organization, there are many many systems and subsystems where data is spread around. SoR are typically viewed as very difficult to put in place and equally difficult to replace as a result. Take an example of a CRM system, for anyone who has actually used salesforce, there are hundreds if not thousands of possible fields to set up in a variety of ways and once the system is set up for use, the users will type in data in a variety of ways which is often very difficult to aggregate so processes and procedures are then put in place to create rules for the sales team.

API (Application Program Interface): These are ways for applications to talk to another application. In the modern age, APIs are extremely important as every large company uses hundreds of applications and ability to communicate with each other is critical. It’s also worth noting that large companies realized that as they become the center of gravity, they are able to charge for tiers of API access “calls” through royalties. Salesforce, for example, has recently dialed up its API monetization in a big way in order to find growth.

Containers: Containers (such as docker) are ways to isolate code from the runtime environment so that you can “lift” it from one place to another. For example, you can containerize a cloud app and lift it into a on-prem or private cloud deployment quickly.

Marketplace: Every large cloud company has a marketplace. It offers smaller partners a distribution channel in exchange for revenue share. This may seem trivial, but for smaller software companies this can often be a meaningful revenue stream because it allows customers to purchase their goods with the cloud providers cloud credits (below). Some security vendors will drive multi-billion revenue streams from AWS alone.

Cloud credits: We’ll get into this in more detail in the business model section but think of this as exchanging a committed amount of cash for a cloud provider (AWS, Google, Azure) cloud credit. You can then use these credits to buy not only the cloud providers offerings but also its partner offers on the marketplace.

CI/CD: Continuous Integration/Continuous Delivery. Software development is a sweat shop factory. R&D organizations are constantly writing code, testing code, deploying them into a repository then into production environments like an assembly line. So naturally, software developers have come up with tools to automate and make this effort more collaborative, hence a series of vendors who now provide these developer facing tools to help with software development itself.

Stay tuned for part 2.

Dark = apps (SaaS)

Light= Infrastructure (PaaS and IaaS)

Investing in any one of these companies would be dangerous, but when taken together as a portfolio, I do believe its possible to achieve above market returns. My goal is to track this over a 2-3 year horizon and see how they achieve against ARKK and the NASDAQ, starting date of March 17, 2023. To make this more tangible, I’ve allocated $200k of personal capital to this little experiment. Equal weighed across 38 companies.

For starters, lets be clear on the following:

• Many of these companies will not make it

• Many of these companies will need dilutive financing to continue

• Many of these companies have significant headwinds (mortgage, credit, etc.)

• Many of these companies risk, even if they stay afloat, might end up being Zombies that go no where

Having said that, many of these companies also have potential to be something big if their vision is realized. To give a few example:

• If SoundHound can gather broader adoption, it will be the only credible standalone voice recognition technology that exists outside of Amazon, Microsoft

• If Origin succeeds, it would become the leading de-carbonization platform

the portfolio also includes a set of companies that I consider to be deep value in tech where liquidity isnt an issue but the macro backdrop has caused them to re-rate to a level where they are cheap but doesn’t offer a compelling near-term reason to own individually (RNG, ZENV, etc.)

So how does the math work? To double my money over 5 years (roughly 15% CAGR) Here’s a few example scenarios below - my baseline is 30-40% mortality rates:

• Mortality rate of 60%: Need remaining to 6.5x over 5 years

• Mortality rate of 50%: 5x

• Mortality rate of 40%: 4x

• Mortality rate of 30%: ~3.3x

• Mortality rate of 20%: 2.75x

• Mortality rate of 10%: ~2.3x

• Mortality rate of 0%: 2x

Here is the list (EV values are from CapIQ so not precise and maybe wrong):