When Tim and I started Basis State, we considered carefully how to maximize the acquisition offers received by our clients. Our process was designed with the expectation that every client could find an acquirer. We now appreciate that this is not the case, particularly in the current environment. We plan to publish our success rate […]
What we see is that acquisitions are still happening in specific sectors, though at a slower pace with lower valuations, with a higher focus on immediate returns.
Even in the best of times, most sub-scale startups treat documentation, process, and exit preparation as a chore to be done later. But as these companies (SellCos for rest of this article) look towards a potential exit, they will quickly realize how much work needs to be completed just to satisfy due diligence in an acquisition.
Basis State, LLC is pleased to announce the successful acquisition of client company EduLync by a leading educational software company.
When acquirers buy a sub-scale SaaS business, it’s rarely for the business’s revenue. The revenue-based valuation rules that apply for scaled SaaS companies do not apply sub-scale.
Instead, sub-scale SaaS valuation is based on the particular reason the target is receiving interest, and this can vary.
As I’ve mentioned in previous articles, there are three main reasons why companies acquire sub-scale SaaS: (1) to accelerate a roadmap, (2) to access a new type of customer, (3) to avail a new product to existing customers.
This article will discuss reason #1; you are being acquired because a company believes your tech will accelerate their roadmap. There are 3 factors to consider in this scenario.
Factor 1: Acquirer’s Cost of DIY
The most obvious element of value in buying vs. building is that the buyer doesn’t have to pay their cost to build. I’ve heard a lot of entrepreneurs mistakenly assume that this is the only, or perhaps primary, component of value. “Why would they buy my co. for $X when they could just build it for $Y?” The answer is, there’s value way beyond the direct cost to build. Still, the cost to build represents value and should be factored.
To quantify, first consider the ways in which big companies do things differently. They tend to pay more for labor, they tend to have more project overhead in the form of product & project management, and projects tend to take longer because of all the various functions peering into development.
The extent of these differences will depend on the size of the co., where they’re located, culture. The point is, think in terms of what it would cost the acquirer to build, not what it cost you to build.
Factor 2: Foregone Opportunity while DIY
More than cost savings, the acquirer wants the ancillary benefits of the new feature…just sooner. To quantify this factor, calculate these benefits over the time period it would take the acquirer to develop.
The value might come from any of these effects:
- Increased close rate
- Decreased churn
- Ability to charge more with the new feature
- Cost savings (a more efficient workflow, lower infrastructure costs)
Tiny changes in large revenue streams create lots of incremental dollars. If a big company can have a revenue-impacting feature a few months earlier, it can make a big difference.
Factor 3: Integration & Transaction Expense
No one likes working with someone else’s code. Building it yourself, there’s no learning curve, no undesirable design to undo, no unwanted redundancy, no messy integration. Further, even the smallest acquisitions usually carry a cost surpassing $100K in due diligence and legal expenses. The size of the Integration & Transaction factor will depend on how dissimilar your code is to the acquirer’s, and how complex the transaction. Nonetheless, it’s important to remember to discount the value calculation by Factor 3.
Putting it all Together
The equation for setting your value looks something like this:
Acquirer’s Cost of DIY (+)
- Developer cost at acquirer
- Admin / project overhead cost at acquirer
- Timeframe to complete at acquirer
Foregone Opportunity while DIY (+)
- Time to develop
- Increased close rate
- Decreased churn
- Upcharge potential
- Cost savings from efficiency (workflow, infrastructure)
Integration & Transaction (-)
- Learning curve
- Integration time
- Ongoing redundancies
- Due diligence & legal expenses
You’ve developed a feature that enables a user to create an explainer video with a few clicks. Big Marketing Platform has been working to develop this feature, but it’s been slow going. Competitors have released the feature, prospects are taking notice, and users are starting to complain.
It cost you a small seed round to build the software, but that’s irrelevant. Big Marketing Platform pays its developers $160K/year and it would need 3 of them to build this over the course of 3 months. In addition, the build requires 50% of a project manager’s time at $120K/year and 25% of a product manager’s time at $200K/year. Big Marketing Platform loves meetings, so the 3 month build would likely expand to 6 months.
So the cost is:
Dev. $160K/12*6*3 = $240K
Prod. & Proj. Mgt. ((.5*$120k/12)+(.25*$200K/12))*6 = $55K
Big Marketing Platform’s product is not showing as well as it did before competitors launched the video builder feature, and some current customers are upset. Adding the feature would increase close rate by 5% and decrease churn by 10%. Over the next 6 months, Big Marketing Platform is expected to do $20M in bookings and have $5M in churn. Adding your feature would create (.05*$20) + (.1*$5M) = $1.5M
You’re a small company with limited operating history, and this is an asset sale. So the acquirer’s due diligence and legal expenses will come in at around $100K. You expect that integration and learning curve will take a month, and will involve the full time effort of 3 developers and 50% of a project manager, or $45K. Double that because maintaining someone else’s code sucks indefinitely. So total factor is $190K.
So your value is $295K + $1.5M – $190K = $1,500,105
One big takeaway from this exercise is that the bulk of your value resides in the foregone opportunity. I find this is almost always the case.
A Side Note on Negotiating
Remember, whatever calculation you’ve made will be wrong in the acquirer’s eyes. The acquirer will have its own set of calculations from real inputs, and in their view, will arrive at the right valuation. Use your numbers as a guide to understand how they are thinking about value, but don’t get too stuck on them.
“When they teach you how to drive a racecar, they tell you to focus on the road when you go around a turn. They tell you that because if you focus on the wall, then you will drive straight into the wall.” – Ben Horowitz
Ben Horowitz has a great point. There are a myriad of pitfalls that can kill a startup, and worrying about all of them while trying to execute is a folly.
But I have found that not being aware of them at the outset is also a mistake.
I have spent a lot of my career looking into startups that are falling short of where they aimed originally. They are headed for the wall, if they are not already pinned up against it.
For the most part, these companies were not doomed from the outset by a bad idea. Nor did they make a single big mistake. They usually had one bad habit that ground away at them over time, until the only thing left to do was to make a hard turn to avoid crashing.
The most common bad habits:
- Staying in the basement too long (over-speculating, over-designing, over-building)
- Concession strategy, trying to be many things at once
- Being slow to pivot when the evidence is screaming the right answer
- Scaling prematurely
And you can usually spot the bad habits without having any company history, just by meeting the founders. Founders who love the tech are prone to staying in the basement too long. Founders who are gentle are prone to concession strategy. Founders who talk better than they listen are prone to being slow to pivot and scaling prematurely.
We all have tendencies that pull us in various directions. It’s important to understand those tendencies, and how they can pull you towards the wall if you if you don’t design ways to guard against them.
Weak tendencies, just being aware of them could be sufficient.
Stronger tendencies, you might need to find a co-founder who can counteract.
And the strongest tendencies might dictate which kinds of startups you are capable of leading. For example, I don’t like long odds over long timeframes. I will not build the next Facebook, because in 2006, I would have snapped-up Yahoo’s $1B offer in a second. Had my co-founders disagreed with me I would have remained firm. Had my investors disagreed with me I would have remained firm. And in hindsight, I would have been dead wrong and responsible for an immense disservice to all stakeholders. So knowing that tendency steers me away from taking on go-long / go-huge plays.
In short, know thyself, and study failure before you start. Understanding all the ways in which you could hit the wall will help you set up your venture in a way that lets you focus on the road.