1 February 2023
How to Prepare your Software Product for an Acquisition
In the last year, two Launch Scout clients have been acquired, primarily for their SAAS software products. Our work on these projects started long before the initiation of the M&A process, so we had a unique perspective on the impacts on the software products and the development team’s priorities. A strategic acquirer of a software product seeks to integrate it into their business or to complement an existing product. They’re looking for reach into new markets, a new revenue stream, or a strategic capability they didn’t have before. In the process of a possible acquisition, they’ll be especially interested in mitigating potential risk and proving that the acquisition can be completed successfully. Here are three aspects of your application that will need review leading up to a possible acquisition.
Security and Legal Concerns
Ensuring a software product is free from significant security vulnerabilities requires reviewing and managing everything in your technical environment. You’ll need to review your source code access control, application’s dependencies, framework and language versions, development practices, deployment and hosting infrastructure, and DevOps practices. Because of the legal responsibility required in an acquisition, checking the boxes is NOT good enough. Document the shortcomings, address what you can, and be honest about outstanding issues. It’s better to be transparent and seek a resolution for these issues in the transaction rather than try to bury them. In addition, it’s a good idea to hire an application security penetration testing firm to receive a third-party opinion of your application’s security.
Technical Debt and Code Quality
Take a sober assessment of the quality of your codebase, looking at things like maintainability, testing practices, and architectural patterns in the codebase. The health of the codebase today indicates how well your application can meet the needs of the business in the future. Ideally, your architecture was designed to allow significant changes to the domain model or user interface. An application with tight coupling will be costly to change and can make the acquisition infeasible. If you’re still a few years away from a possible acquisition, ensure your application architecture isn’t painting into a corner. The worst-case scenario of a SAAS product that fails to be acquired because of poor technical foresight and decisions does come true, and it’s often the death of the product.
Business Integration and Revenue Expansion
Frequently a potential acquirer will want to see a demonstration that the product can integrate into other areas of the business. For example, adding CRM integration shows that the application can scale with an increased sales demand. Many SAAS products have limited integration initially built for sales, marketing, customer service, and finance. If you don’t currently support these integrations, you should expect them to come up in the due diligence conversations. They’ll likely be items on your product roadmap within the first year post-acquisition.
Have you been part of a software acquisition recently? Let me know if I missed something or if you have one to add to the list.