Much of the value of a SaaS startup lies in its technology. Before you Acquire one, you must review the technical foundations upon which the startup is built. Cracks could result in collapse later, derailing growth plans and losing you time and money in repairs.
Start technical due diligence early, before you’ve made an offer. An otherwise healthy startup might hide a plethora of issues on the back end. Honest founders will happily share technical data if it helps de-risk the acquisition for you, so don’t be afraid to ask for it.
You needn’t do everything yourself and shouldn’t if you’re not qualified to do so. At the very least, however, you should know what’s expected of the founder. The onus is on them to prove the solid technical foundations of their startup. Any hesitation here speaks volumes.
Here’s a brief list of things to review that you can use a sort of technical due diligence checklist.
Who Should Do Technical Due Diligence?
As the buyer, you’re responsible for technical due diligence, but you needn’t be the person doing it. Technical due diligence requires technical expertise.
“I’m an engineer,” you might argue, but do your skills and experience qualify you to assess the technology of the startup you’re acquiring? You might be an expert in Python, for example, when the codebase is written in Java.
Unless you’re a polyglot programmer, it’s okay to say no and get professional help. You might ask a good friend or business associate to help, or even better, hire an agency to do technical due diligence for you. They’re expensive but worth it.
What Are You Acquiring?
Most SaaS startups are Acquired in an asset purchase, which means you’re acquiring intellectual property (IP). Your first step is understanding what that IP is, who built or developed it, and what architecture and software languages it uses. This weeds out potential ownership disputes early and sets the assessment criteria for later stages.
This is also a good time to ascertain who’s the best person to speak to. It might not be the founder but a CTO or other technical expert in the founder’s team. You’re going to ask many questions and you don’t want them or their answers delivered second-hand. If the founder is hesitant or evasive about sharing information or connecting you with technical people, proceed with caution as they might be hiding something.
Obtain Documentation and User Guides
A founder worth their salt will have documented their technical operations. Some might even have written a manual that lists their technology (owned and third-party), licenses, patents, processes, customer flows, and so on, with diagrams representing how everything interacts. Use these insights to verify all is what it seems.
Documentation, or a lack of it, can also help you decide whether a startup is worth acquiring. A founder that wrote a technical guide to their startup has likely been as assiduous in other areas or been preparing for an acquisition for some time, both of which are a good sign. A founder with scant or no information, however, is a red flag and should be avoided.
Review the Code
When it comes to technical due diligence, code is critical, specifically:
Is It of Good Quality?
Programming is part science, part art, and there are many ways to skin a cat (sorry cat lovers). There will be notation preferences, organizational preferences, simple ways of doing things and workarounds that achieve the same result. You need to establish what you can work with and what needs to be rewritten and whether you have the resources (and will) to do so.
Is It Fit for Purpose?
Beautifully-written code isn’t always effective code. It should be efficient, scalable, and customized to the startup’s specific value proposition. Anything else adds unnecessary complexity and cost. Third-party or open-source integrations, for example, might be better developed in-house where you have greater control over cost and performance.
Ask to View a Software Composition Analysis Report
It’s common for SaaS startups to rely on open-source software. Why write everything from scratch when you could import ready-made, interoperable, and flexible code for free? Technical teams can then spend more time creating great products. However, too much open-source code can expose a startup to security vulnerabilities and licensing issues.
As part of technical due diligence, you should ask to see a software composition analysis report to evaluate the risk of open-source integrations. If the founder can’t provide one, insist on it before moving forwards with the acquisition, especially if the code is mostly open-source. You don’t want to inherit libraries of copyright infringements and security liabilities.
Who Owns the Code?
Beyond open-source, who else might have claims on the code? Software composition analysis will reveal infringements on open-source libraries, but are you certain the remainder of the tech stack is owned by the founder?
Ask to see patents covering the startup’s technologies. If none exist, ensure code isn’t infringing on others’ copyright, and with that settled, consider how easy the tech is to duplicate. Could another startup reverse-engineer the software and launch a competing service?
It might also be worth asking to see signed Non-Disclosure Agreements (NDAs) and employee and contractor contracts to ensure they gave up rights to what they produced on company time. Otherwise, you could face a nasty court battle over IP rights.
How Secure Is the Technology?
The composition analysis report will identify problems with open-source code. But how secure is the rest of the tech stack? Does it meet system and data security standards such as ISO/IEC 27001 and ISO/IEC 25010? You should ask for evidence of quality assurance, testing, and reporting procedures, as well as a multi-party (ideally) code review-and-deployment process.
Application failure can cost as much as $100,000 per hour. Check the founder has a business continuity plan in place that outlines what happens when there’s a system outage. How is data recovered? Are there alternative servers you can switch to in an emergency? This gets more complicated the more third-party integrations exist, so a detailed plan is critical.
Get Customers’ Opinions
Customers offer an objective, unfiltered window through which to assess the startup’s technical prowess. Start with reviews, case studies, and testimonials. Focus on what they report about the product: how well it works, how it compares to competitors, bugs and annoyances, and so on. Has the founder listened and responded to feedback or will you inherit these grievances?
Then, ask for access to the IT reporting system. How easy is it for customers to report bugs, feature requests, feedback, and so on? How quickly are tickets resolved? How many tickets are outstanding? Are these easily fixable or require reconfiguring a system or process? Look for evidence of customer-driven development, which demonstrates a strong, agile product.
Who’s Behind the Software?
Technical, product, and design teams are the beating heart of a SaaS startup. Before you Acquire one, establish who’s staying on and who’s leaving, what their abilities are, and who must stay to make the acquisition successful. Unless you have a team standing by, don’t Acquire a startup with a talent vacuum as you risk stalling post-acquisition plans.
Technical due diligence applies to the people building the software just as much as the software itself. Ask to view CVs and the authors of features you like best. An organizational chart will help you identify the stars and supporting roles. For those whom you want to stay, consider incentives such as pay rises, equity, and bonuses. (You’d spend the money on replacing them, anyway.)
What’s in the Roadmap?
Product roadmaps give purpose to a SaaS startup’s technology. They also help teams understand how their goals align with those of the startup. As such, they can be powerful motivators and ensure everyone strives for the same outcome, regardless of their role. This all points to an easier time post-acquisition since you can leverage such razor-edged focus to your advantage.
You needn’t follow the roadmap, of course, but if the founder has gone to the trouble of creating one, it reveals two things: one, they believe in the long-term potential of their startup, and two, how you might grow revenue in the future. A startup without a roadmap, however, is a boat adrift on open sea: a founder who has yet to understand the problem their startup solves.
The founder should collaborate with you on technical due diligence. However, they might resist sharing sensitive information or intellectual property and you should respect that. Start technical due diligence early using publicly available information and then ask for more as negotiations progress.
Learn more about acquiring the best startups on our blog. Or if you’re in the market for a new venture, choose from 1,000s of vetted startups on our marketplace.
