Considerations Unique to Acquiring a Software Company (Product)

Listen to this Blog Post:

In a previous blog post, I discussed several financial considerations unique to acquiring software companies, specifically those of the small-to-medium-sized variety . In this week’s post, I present several non-financial considerations for the prospective acquiror to consider.

Much of what I discuss below is intended to uncover how much “technical debt” any given target company may possess within their code base (I will define technical debt shortly). Though substantially every software company has some amount of technical debt, those that are weighed down by an asymmetric burden of it tend to:

• Ship code less frequently;
• Struggle to keep pace with competitors;
• Release fewer new features and spend more time fixing bugs;
• Regularly miss release targets;
• Possess code bases that are difficult to build upon;
• Have slower implementations;
• Generally be much more expensive and capital intensive to operate and grow

In this way, what start out as technical problems quickly accumulate and become significant business problems.

Too much technical debt can significantly impair the ability of an acquiror to grow that business, and can necessitate additional time, cost, and energy not originally contemplated in the initial investment thesis.

As a result, prospective acquirors would be well served to thoroughly diligence the amount of technical debt possessed by any given target company, and proceed very carefully (or perhaps not proceed at all) with those companies who seem to possess much more than their fair share of it.

What is “Technical Debt”?

In essence, technical debt refers to the accumulated impact (measured in time, cost, and required rework) of product and engineering decisions that prioritize speed over quality and scalability.

At the risk of oversimplifying, when software engineers develop any given feature, they typically operate on a spectrum bookended by two extremes (though most work that gets done usually falls somewhere in between them):

1. Approach 1: Deliver the feature as quickly as possible, with things like quality, scalability, and extensibility being secondary considerations (if they’re considered at all)
2. Approach 2: Develop the feature in a way prioritizes scalability, extensibility, and high quality over speed (though this necessitates much more time, it ultimately produces a better work product).

Though the external observer might reasonably conclude that Approach #2 should prevail 100% of the time, that rarely happens in reality. Often, non-technical considerations compel engineers to follow an approach that more closely resembles Approach #1 (things like time-sensitive feature requests from important customers, promises made by the sales team, or pressure to hit a deadline).

Though it’s understandable (and perhaps even expected) to see features developed under approach #1 from time-to-time, if too many features or products are developed in this way for too long of a period of time, then technical debt begins to accumulate within the code base.

With this context in mind, another definition of technical debt emerges: It’s the cost of making too many “make it work” decisions (Approach #1), and not enough “make it right” decisions (Approach #2) over too long of a time period.

Technical debt shares many parallels with monetary debt, in that:

1. It is not necessarily a bad thing, but too much of it certainly can be
2. It must be regularly repaid (often by reworking or even rewriting the underlying code in question), otherwise its balance will continue to grow and accumulate, which will in turn create further problems
3. The debt eventually, and always, comes due (debt in a code base can “come due” in any number of ways, including the various business problems that I listed in my introductory remarks).

Building on top of a code base that is riddled with technical debt is akin to building a house on top of a foundation that you already know is cracked, leaky, and unstable: No matter what you do with the rest of the house, the stability, structure, and overall soundness of the building will always be inherently compromised. 

Ways to Identify Technical Debt

The good news is that there are things that one can look out for that may suggest that a company is shouldering more than their fair share of this problem. I list these considerations below, and break them out into three different risk categories:

1. High Risk (strong indicator of technical debt)
2. Medium Risk (likely indicator of technical debt, but more investigation is likely required)
3. Lower Risk (things that may suggest a risk of technical debt, but aren’t signs of it in and of themselves)

High Risk Signals

(1) Percentage of Releases Dedicated to Maintenance vs. Innovation

Analyze every feature or product release over each of the past two years, and categorize those releases as either “maintenance” releases or “innovation” releases. “Maintenance” releases can be thought of as those that are necessary for the product to keep functioning, but don’t really include new features or functions that users ask for, notice, care about, or are willing to pay for. These releases usually include things like bug fixes, code clean-up, scalability work, security work, failover work, and so on. “Innovation” releases include new, forward-looking, visible features that customers are ask for, notice, care about, and demonstrate a willingness to pay for. These often come in from sales, get voted up on user boards, or at least provide customers with new or different pieces of functionality.

In companies with a lot of technical debt, you will often see anywhere from 50% – 100% of releases being of the “maintenance” variety. This often suggests that the engineering team is so busy simply trying to keep the product afloat that they have no time to meaningfully improve it in a way that will generate an incremental willingness to pay from customers.  The longer this dynamic persists for, the more problematic it becomes for the potential acquiror: If Company A has spent the past 3 years simply keeping their product afloat on account of too much technical debt, then Company B (their direct competitor with less technical debt) has likely spent those same 3 years building new features and functions that likely now significantly differentiate them relative to Company A in the eyes of customers.

(2) “Escalations” From Various Internal Groups into Engineering

In a company with a lot of technical debt, the Engineering group often receives a lot of “escalations” (defined as very urgent bugs to be fixed or features to be added to “unstick” any given customer) from internal groups, usually from Support, Customer Success, or Professional Services. In an ideal world, no new incremental code should ever need to be written to implement or onboard a new customer, nor to address any existing customer’s support tickets. One way to measure this is to simply measure what percentage of overall developer time is spent on escalations from internal groups that are not explicitly included on the company’s roadmap. The higher the number, the more concerned one should be.

(3) Modules, Features, or Products Specific to One Customer (or a Small Number of Them)

In enterprise software, there is perhaps no word that is as scary or as dangerous as “customization”. As product management thought leader Rich Mironov regularly says, truly successful software companies essentially aim to sell identical bits of code to as many customers as possible. One can see why the strategy of “build once, sell many times” is much more economical than that of “build many times, sell once each”. One way to identify this is to get a list of all customers, including an inventory of all products, modules, and add-ons owned by each of them. You’re ideally looking for this list of products to be as uniform as possible. If you see certain modules, add-ons, or products that are only owned by a single customer (or a very small number of very similar-looking customers), then you’d be wise to investigate further to ensure that these haven’t been customized to the specific needs of any of them.

Closely related to this consideration is the extent to which the company’s offerings are properly “productized”, meaning that they’ve been clearly delineated into individual SKUs, and those individual SKUs have in turn been sold into multiple customer sites. Non-productized software offerings can sometimes signal a risk of technical debt: In its most extreme form, consider a custom development firm, which simply develops any piece of software requested by customers. They don’t have any SKUs to sell in particular beyond the time and materials of their development group. Companies like these operate under the ethos of “build many times, sell once each”, which is about as inefficient as it gets in the world of software development.

(4) An Old Technology Stack

A “technology stack” essentially refers to the combination of tools, technologies and languages that software companies build their products on top of. To the extent that they’re using old technology (that has either been deprecated, is no longer supported by its provider, or at the very least just isn’t widely used any longer), there is a reasonable chance that a lot of time, money and effort will be required to simply bring that code base into the modern day (without the addition of any new features or functions, which at least (typically) would present a revenue case associated with them). Any experienced technical advisor or software industry veteran can advise on how current any given tech stack is across both the back-end (non-user facing) and front-end (user-facing). The older the tech stack and code base, the more likely it is that you’ll have to expend a lot of resources trying to dig yourself out of that hole.  

(5) Quality Assurance: Size of Team & Manual v. Automated Testing

A critical part of any engineering operation is the Quality Assurance (or “QA”) team, that is responsible for vigorously testing the code written by their peers in the engineering group . There are two primary clues to look out for that might suggest that a company has under-invested in QA, and the more that they have under-invested, the more likely it is that they are accumulating meaningful technical debt:

(a) The Size of the QA Team: In my experience, there should be roughly 1 member of the QA team for every 2 members of the engineering team

(b) The Relative Mix of Manual Testing vs. Automated Testing Within QA: Over the past 10-15 years, countless tools have come onto the market that automate certain tests that QA teams have to run: A script is written one time, then that script can be applied against every new feature or product to test for the variable that it was designed to test for. You can see how hundreds or thousands of automated test cases can significantly scale the efforts of the QA team. On the other end of the spectrum there is purely manual testing, which is exactly what it sounds like: Individual members of the QA team manually evaluate the code base and the UI to look for bugs. You can see how unscalable this approach is, and thus how many bugs/errors it is likely to miss. You want the percentage of all tests represented by automated tests to be as high as possible.

Medium Risk Signals

(1) Source, Frequency, and Cadence of New Feature Releases

If a company isn’t regularly releasing new features, functions, and/or products (“innovation” releases, as described earlier), it could be a sign that their development team is too overwhelmed with “maintenance” releases.

In addition to the frequency of releases, the source of new feature release ideas could be equally informative: In companies with a lot of technical debt, those sources tend to be more internal than external, and often feature Support, Customer Success, or Professional Services urgently requesting new functionality to address an immediate-term problem faced by a single customer. In companies with less technical debt, sources of new releases tend to be more external than internal, as they face fewer such instances.

Why This isn’t a High-Risk Signal: Many small-to-medium-sized software companies, especially those that have been owned by the same person for 10-20 years, tend to be more inward-facing than they ought to be (and the Founder/Owner/CEO often acts as the unofficial “Head of Product”), so the source of new features requests, in and of itself, isn’t necessarily a high-risk sign. Further, some businesses that fit this description eventually come to be run as “lifestyle businesses” for the Owner/CEO, where she aims to maximize the personal economics that she can extract from the business, as opposed to investing more in something like product R&D. This dynamic could be the primary driver behind fewer new releases, as opposed to technical debt.

(2) Speed and Variability of Implementations & Customer Onboarding

In many software companies, after an initial sale is made, there is some sort of set-up, configuration or onboarding that must be done in order for the new customer to use that product, often performed by a Professional Services or Customer Success group. To the extent that work is paid (usually on a simple cost/hour basis), you will want to pay close attention to:

• % of Unbillable Work: A Professional Services or Customer Success group will often provide customers with a Scope of Work prior to engaging with them that outlines what work is to be done, and what represents billable vs. non-billable work. Though it is indeed normal for some “scope creep” to emerge during the course of any given implementation project, and is similarly normal for some work to be of the “unbillable” variety, too much of either of these dynamics may be suggestive of a product that requires the involvement of engineering to facilitate a smooth implementation, either because bugs in the code are regularly identified, or new functionality specific to single customers needs to be added.

• % of Projects that Come in Over Their Original Time Estimates: If, for example, a 40-hour implementation regularly takes the company 60 hours to perform, it is at least possible that each implementation is so unique to any given customer that there are at least 20 hours of “unknown time” inherently baked into each project. Again, if those unknowns exist due to bugs or features specific to any given customer, then that could be suggestive of technical debt.

Why This isn’t a High-Risk Signal: Though these issues could be attributable to technical debt, they could also simply be reflective of an ineffective Professional Services or Customer Success operation. Perhaps they are ineffective at properly scoping the work, properly staffing each project, or properly accounting for their billable vs. unbillable time.

(3) Lack of True Product Management Processes

The simplest description that I’m aware of regarding the role of Product Management is as follows: Product Management decides what to build and why, and Engineering decides how to build it. In my opinion, Product Management is one of the most important disciplines to get right when building a successful software company, and for that reason, it may serve as a warning sign when you see a software company that is totally bereft of its basic tools, structures, and processes. Indeed, a glaring lack of these things could represent a key ingredient in the creation of technical debt. Below are just a few of the possible signs that could be suggestive of an environment where there is a lot of technical debt looming below the surface caused by a lack of Product Management discipline:

• The company has no process for evaluating and prioritizing new feature, function, or product requests (often the Owner/CEO acts as a sole arbiter of such decisions)
• Employees or customers go straight to software developers with product or feature requests
• Software developers often decide, in their sole discretion, what to work on and why
• True product/feature requirements are not gathered before coding begins – they’re essentially arrived at as the coding process unfolds

Why This isn’t a High-Risk Signal: As mentioned above, it is not necessarily abnormal for a small-to-medium-sized software company, particularly one that has been owned by the same entity for 10-20 years, to lack Product Management best practices. For this reason, I wouldn’t be frightened by this dynamic in and of itself. However, potential acquirors would be well served to proceed with due caution if they see too many of these factors at play.

Lower Risk (But Possible) Signals

(1) Capacity Issues in Support or Required Size of Support Team

A software company’s customer support team is generally responsible for fielding customer questions and resolving any product or technical issues experienced by those customers. A code base that is high in technical debt often creates a situation where the demands on the time of the support team are extremely high due to the large number of underlying issues within the product. If your target company has a support team that meets either of the following criteria, then further investigation is likely warranted:

• Overwhelmed: The extent to which the team is overwhelmed can be measured by things like (1) Capacity utilization; (2) The number of outstanding support tickets (and its trend over time); and (3) The rolling weekly average of the difference between tickets created and tickets solved (you want to see this number decrease over time, otherwise it suggests that the Support team is getting further under water with each passing week); OR
• Too Large: A support team that is too large relative to the size of the organization might suggest that a team that large is needed to simply field the volume of incoming customer issues. There are no hard and fast rules about how large a Support team should be, but there are a few ways that you can attempt to situate the team’s size into some sort of context:

1. Evaluate the profitability of the team: Naturally, you want your Customer Support operation to be profitable, and likely at a particular margin. Because you will know the fully loaded cost of the support team, you can compare that cost against the relevant streams of revenue to see if the group is sufficiently profitable

2. Compare to the size of the Development team: For example, if you have 10 developers creating products, but require a support team of 10 to fix those same products, I would suggest that there is a potential imbalance to investigate

Why This isn’t a High-or-Medium-Risk Signal: Of course, these issues could just be representative of an inefficient Support operation, including under- or over-staffing, lack of sufficient tools to track and maintain outstanding tickets, etc.

(2) Number of Developers as a Percentage of the Total Employee Base

While this number could be high or low for any number of different reasons, and in and of itself could mean a number of different things, prospective acquirors should inquire about development teams that are asymmetrically large relative to the size of the rest of the organization. If these teams are regularly releasing new features and functions with sufficient speed and quality, then it’s likely not a sign of technical debt. However, if asymmetrically large engineering teams aren’t regularly shipping code, releasing new features or products, or building code of suitable quality, then that may be a sign that the company requires a large number of developers to simply maintain the product in its current form.

• Why This isn’t a High-or-Medium-Risk Signal: As mentioned above, development teams can be large for a number of different reasons. Consider the example of a young start-up building the first version of their product: The company could be almost exclusively composed of engineers until the product and company is ready for supporting operations like Sales, Marketing, HR, Customer Success, and so on.

(3) Concentration

Though concentration is relatively common in SMBs (customer concentration, supplier concentration, channel concentration, etc.), it doesn’t come without its obvious risks. Specific to product, high levels of concentration can sometimes manifest in the code base if the company is so dependent on a single customer/supplier/channel partner that they feel absolutely compelled to add anything and everything that the partner requests of the product, for fear of losing that relationship. Blindly acquiescing to the requests of any stakeholder is one of the leading reasons why software companies (particularly small ones) accumulate technical debt over time.

Why This isn’t a High-or-Medium-Risk Signal: Concentration doesn’t always manifest in the code base. It’s simply something to look out for if the business in question is heavily dependent on a single stakeholder (or a small number of them)

I’ve Identified a Target Company that has a lot of Technical Debt. Should I Cease my Pursuit of Them?

In my opinion, the answer is no, but it probably goes without saying at this point that you should proceed with a very healthy dose of caution. Here are just a few illustrative examples in which it may still make sense to proceed (though for each instance I provide reasons why caution is still very much warranted):

1. The technical debt has been properly reflected in the purchase price: Though I subscribe to the belief that it’s better to acquire a great business at a fair price than it is to acquire a fair business at a great price, otherwise attractive companies with lots of technical debt can still represent reasonable investment opportunities if the time, cost, and energy required to address that debt has been properly reflected in the purchase price. Buyers must try to help sellers understand that the time and capital spent reducing technical debt usually doesn’t come with a commensurate revenue case (unlike, for example, the development of a new product, that may present similar R&D costs but will at least provide the company with revenue upside to justify those costs). As a result, the buyer will have to incur non-ordinary-course expenses that they wouldn’t have to incur if they were to purchase an otherwise identical company with less technical debt.

Reasons to proceed with caution:

(a) It’s very difficult to estimate both the time and the capital that will be required to get any company’s technical debt down to a more manageable state;

(b) There is likely to be massive asymmetry of information between buyer and seller (the seller is likely to be far better positioned to make the time & cost estimate, but is incented to make the estimate as modest as possible);

(c) Even if you do arrive at a fair estimate, the process often tends to be more time consuming and more expensive than most initially suspect

2. The product is not at all central to the investment thesis: This example may be slightly more controversial, as the product represents the essence of any software company. With that said, it still may make sense to acquire a software business with high levels of technical debt if the other considerations underlying the investment thesis are such that the required product work over the contemplated hold period is largely of the “maintenance” variety. Consider a mature software company that is only growing revenue between 0% – 5% per year, because they haven’t raised prices in 10 years, and don’t have any in-house sales efforts. This company regularly produces $4M of EBITDA with very low levels of customer churn, because customers have very high switching costs, and it would be very time consuming, disruptive, and/or expensive to switch to an alternate provider. Further consider that the company has significant whitespace within a broadly diversified customer base to upsell existing products and modules into those same customer sites, most of whom only utilize the most basic version of the product. Combine that with reasonable leverage when capitalizing the investment and a shorter-than-normal hold period (extra points if you get a compelling purchase price, per my commentary above), and you have the ingredients that may constitute a compelling investment opportunity in spite of the state of the company’s product.

Reasons to proceed with caution:

(a) To say that a product is not central to a software investment thesis borders on being an oxymoron. The product is the heart of any software company, so in order to succeed in spite of it, many other stars need to be aligned

(b) Even if you get an attractive purchase price to reflect the technical debt, a cheap multiple on the way in may mean a cheap multiple on the way out too (especially if you’re contemplating selling to a sophisticated acquiror, and/or if you don’t properly address the technical debt during the course of your own ownership period). Almost any experienced software investor to whom you will attempt to sell the business will likely be able to see these risks

(c) Any time that one makes an investment where a certain variable has to be a certain way in order for the investment to succeed (in this case, the product must not buckle under its own weight during the contemplated hold period), there is considerably more risk involved

In Sum

Software companies that are burdened by an asymmetrically large amount of technical debt tend to ship code less frequently, struggle to keep pace with competitors, release fewer new features, spend more time fixing bugs, and are generally much more expensive and capital intensive to operate and grow. What initially present themselves as technical problems quickly accumulate and evolve to become significant business problems for the prospective acquiror to carefully consider.

Though some technical debt is to be expected, too much of it can render an otherwise compelling investment thesis moot. For this reason, acquirors must be very thoughtful in their analysis of both the product and the code base, to ensure that the product – the foundation on which the company is built – can stand up to their plans for future growth.

---