Understanding the capex requirements of a business is essential to investors since it helps to determine whether an asset offers an attractive rate of return. Capex is commonly misunderstood when it comes to software businesses, so I’ve decided to break it down and also share what I look for when assessing capex in software deals.
What is Capex?
Capex (short for capital expenditures) is money that a business spends to maintain or grow its asset base. It’s different than opex (short for operating expenditures) which is money spent on an ongoing basis to generate revenue from assets.
Let’s use a factory example because that’s easy to conceptualize.
Capex is the cost of building the factory, including the construction costs (salaries of construction workers and materials), the cost of machinery, and equipment. Capex ends up on the balance sheet as assets.
Opex can be best described as the costs associated with operating the factory, such as the factories’ salaried line workers, electricity to power all the machines, and insurance to protect the day-to-day operation. Opex ends up on the profit & loss statement as expenses.
Maintenance Capex vs Growth Capex
Capex can be further divided into maintenance capex and growth capex. Maintenance capex is the cost to maintain an existing factory, such as replacing machinery/equipment and repairing the building. Maintaining the existing factory is required to retain the existing revenues, customers and capacity. A high maintenance capex (relative to EBITDA) is generally a negative sign, as it means the business has low profitability.
Growth capex is the cost of building a brand new factory in order to expand capacity, attract new customers, and generate net new revenue. Growth capex, assuming the rest of the math and business economics makes sense, means investors can expect earnings to continue growing in the future. An important dynamic about growth capex is that it is completely discretionary. Management can decide whether to pursue growth capex or not, without the existing business being affected. (remember this for discussions below).
How Capex Works in Software
In software, capex is basically R&D expenditure or salaries paid to developers. Accounting rules give businesses the option of capitalizing these costs onto the balance sheet as assets. You need to, however, prove how specific developer costs actually created intellectual property (aka an asset that will generate future revenues) to accountants/auditors, which can be hard to do. And even when you do manage to properly capitalize R&D costs, each year that goes by, you’ll need to prove the asset value still exists. Choosing to capitalize can also be risky because if you over-capitalizing, or improperly impair or amortize the intellectual property you’d be breaching accounting standards. As a result, capitalizing R&D costs is a massive administrative burden.
For the reasons above, in practice, the vast majority of software companies opt not to capitalize R&D expenditure, and instead just expense developer salaries through the P&L. This creates a challenging task for software investors as it’s hard to tell the value of the assets a software business has, it’s maintenance capex and its growth capex.
Growth vs. Maintenance Capex in Software
Now that we understand that capex flows through the P&L for software companies, the next step is differentiating between growth and maintenance capex. For traditional companies, amortization/depreciation is a fairly decent proxy for maintenance capex. But since software companies don’t have amortization/depreciation, how do you determine maintenance capex?
That’s the neat part… you can’t.
Software is still bound to the laws of physics that any other business is bound to. Speed is limited by gravity, which in this case, is maintenance capex. But for some reason, the R&D expenditure that software companies endure often gets a pass from investors. Many investors chalk it up to growth capex and conclude that software businesses are simply “investing through the P&L“. But if investors were to scrutinize the R&D expenditure in more depth, they’d be unpleasantly surprised to find out that a big chunk of it is actually maintenance capex.
In the case of software companies, let’s divide the maintenance capex further into 2 more buckets: Type 1 vs Type 2.
Type 1 maintenance capex – these are costs related to fixing bugs, upgrading security, and patching other holes. The spend here depends on the age of the software, how well the codebase was structured/built and how well it’s been maintained over the years. Older software, unscalable codebases, and negligent maintenance lead to technical debt and these costs can compound over the years. Type 1 maintenance costs are obvious and are universally agreed upon as maintenance capex.
Type 2 maintenance capex – these are costs related to adding new features, functionalities, modules, and integrations. On the surface, it may appear like this is growth capex, since these expenses seem discretionary and not necessary to maintain the existing customer base. The problem is, many software businesses are engaged in an arms race of shipping new features/functionality. In many industries, this type of spending becomes mandatory just to maintain existing customers and attract the same level of customers. In these situations, the moment you cut R&D spending, you lose existing customers and or potential new customers to competitors who don’t cut their R&D spending.
This clearly is not discretionary growth capex, or building new factories to expand capacity and access new customers. This is replacing the machines inside your existing factories very frequently in order to continue to service the same capacity.
It’s the classic prisoners’ dilemma situation with an obvious Nash equilibrium (the red box):
This ultimately heightens the level of maintenance capex that many software businesses require, thus reducing profitability and return on invested capital.
What I Look For
As a private equity investor, the type of businesses that I look to invest in or acquire need to have low ongoing capex requirements in order to be defensive in an inflationary environment. Unfortunately, there’s no accounting shortcut to truly understanding the nature of a business and its economics. So you need to look beyond the numbers and take a more qualitative approach.
Here are some of the capex-related things I look for, specifically in software businesses:
Accept Type 1, avoid Type 2 – the Type 1 maintenance capex described above is generally predictable and measurable. Technical due diligence is performed as part of the overall DD process for any software acquisition I am involved in. This will give me a sense of how sound the codebase is, and how well it has been maintained which affects ongoing Type 1 costs. The good thing about Type 1 costs ( or regular software maintenance) is it can be performed by developers or agencies in low-cost jurisdictions. Type 2 costs (new features/functionalities) often require high-paid and experienced developers with a good business sense, this makes it very costly and extremely difficult to outsource.
Prefer vertical software – the arms race of Type 2 costs usually occurs in horizontal software industries, where the product can be used by any customer. In these types of industries, there is a winner-take-all dynamic as the prize is massive because the addressable market is massive. This basically incentivizes an arms race, the better product wins the whole pot. Vertical software businesses typically cater to a single niche, like law firms, libraries, or insurances customers. Vertical markets are small so the arms race incentive usually isn’t there, the juice isn’t worth the squeeze. This means that vertical softwares often don’t need to spend Type 2 maintenance capex in order to stay competitive.
Avoid VC money – I generally prefer any industry that hasn’t been infiltrated by large amounts of VC money. You don’t want to compete against someone that can ignore capex altogether because they can continue to raise money from VC firms. This irrational spending means they can supercharge their R&D spending, forcing you into an unwinnable arms race. Luckily most VCs don’t invest in vertical niches as the address markets are just too small for them.
High switching costs – I look for software companies that have high switching costs. Businesses with unique and/or customized workflows, those that store a lot of customer data, or any other factor that makes it costly for a customer to switch. If the software is mission-critical to its customers, the mere thought of switching feels daunting, and poses too much of a risk to even consider. These translate into less Type 2 maintenance capex requirements; even if competitors spend on R&D, the cost of switching is simply too costly and risky and therefore not worth it.
Understand churn – Calculating retention rate is important, but understanding the factors that drive retention is just as important. Part of my research and analysis includes interviewing management to obtain a deep understanding of why customers churn. Any indication that customers are leaving due to a lack of features or functionality is a red flag for me. This likely means that there is Type 2 maintenance capex the business will require today and possibly tomorrow.
Understand lost opportunities – similar to the point above, I interview management to learn why the business typically loses a customer opportunity. Again, if features/functionality comes up as a reason, likely means that there is Type 2 maintenance capex the business will require today and possibly tomorrow.
Prefer mature markets – I generally prefer mature software markets as opposed to new or emerging high tech markets. Mature markets mean products improvements have stabilized and much of the R&D spend is on Type 1 over Type 2 maintenance capex.
Final Thoughts
Intangible assets – such as software – redefined capex. I hope this post provided some insight into how capex works in software, and what I typically look for when assessing capex in a software business. A deep understanding of capex is critical for investors (and operators) trying to effectively use funds that will drive the greatest return of investment. After all, profitability and return on invested capital is directly tied to strategically sound capex.
Hi there! I’m Jay Vasantharajah, a Toronto-based entrepreneur and investor.
This is my personal blog where I share my experiences and passion for investing, entrepreneurship, personal financial management, and traveling the world.
Subscribe below, to get a couple of emails a month with free, valuable, and actionable content.
7 thoughts on “Demystifying Capex in Software Investing”