Read Blog Post

Read Blog Post

Contributed on March 6, 2020

144

430

Startups: How to Manage your OEM for Exit Planning

Blog: The Tibco Blog

Reading Time: 3 minutes

In the modern-day startup business, an exit to public markets through an initial public offering (IPO) of stock has become increasingly challenging due to regulatory pressures and less-than-desirable market valuations. Look no further than what happened to WeWork. Today, founders and institutional investors of startups are more focused on developing an exit strategy that involves selling to a larger player in the market. During the course of developing a robust exit strategy, most startups often overlook key decisions while building their product that might cause problems downstream, when future acquirers start to value the business for acquisition. In this short article, we examine the topic of software OEM as it pertains to future acquisition consideration.

In my prior article, Focus your Energy on your Application, not your Infrastructure we compared building infrastructure capabilities for an application software startup to using OEM software for accelerating time to market and other efficiencies. Similarly, when it comes to exit planning there are trickle-down decisions that have to be made at the product level and should be carefully considered as it might impact exit valuations. 

Let’s explore this further with a startup M&A example

Company A and Company B both compete with each other in a hotly contested startup market for next-generation, artificial intelligence (AI)-driven HR software that employs machine learning and lots of data integration. Both companies, A and B, have raised nearly the same amount of venture capital, enjoy similar market success, and both have very good teams. Company C, a large publicly-traded company is now looking to “fold in” a market-leading AI technology into their existing HR application software and has decided to buy either Company A or Company B. 

While going through initial product exploratory calls with Company A and Company B, the acquirer puts a small table together that might look like this:

The CTO of Company A always insisted on using the “best” engineered solution, even if the long-term consequences were not fully vetted. In the case of Company A, the CTO chose to use a myriad of open source tools and homegrown, customized adaptations to address the data integration requirements for their HR solution, which often needed to connect with multiple ‘cloud’ solutions like Salesforce, and ‘on-premises’ solutions like PeopleSoft. In building everything in-house, engineers in the trenches of development made suboptimal choices. When incorporating open-source tools that lacked permissible licenses and also require heavy customization, Company A made it difficult for Company C to merge with their infrastructure. Moving off those investments when an acquisition happened would not be easy for Company C (or any other company for that matter) and would perhaps require a triage-based re-architecture approach at different levels of the infrastructure software stack.

In comparison, Company B has a Founder/CTO who is a pragmatist who continuously optimized for speed to market along with scale and cost of ownership. As such, Company B employed OEM-based tools to address infrastructure needs for connectivity, analysis, and so forth. In addition, the OEM tools have “assignable” contracts, which means they could be easily incorporated into Company C, with little legal risk. They also put in place strict measures behind selecting and using open-source tools without explicit permission from the CTO.  

As evident in the above example, the good intention of Company A’s CTO results in a scenario where, after years of product development, the acquiring Company C has to rip and replace core infrastructure elements of the product to de-risk the acquisition. This will result in a longer path to market after post-merger integration. Given this situation, Company C decides to reduce the valuation for Company A by 30%, which doesn’t sit well with the founders and investors of Company A, and in the end, results in Company B being acquired.

No one approach is the perfect way to grow your software infrastructure investments. There are always pros and cons. That said, it is wise to keep a couple of sacrosanct best practice rules in place as follows:

1. Insist on using permissive licenses, especially when incorporating open-source software
2. When incorporating OEM software into your startup software, insist on “assignable” contracts, so that at the time of acquisition the acquirer can take ownership of the contract with the least amount of legal friction

The best way to think through your infrastructure investment is to consider a balanced strategy that considers speed to market, customer needs, and future acquirer objections that might arise.  

Learn how TIBCO’s deeply embedded OEM solutions can help you get your tech start-up’s infrastructure right and allow you to focus your energy on your applications.