If you’ve never sold a company before, you may not know what to expect. Often, the buyer will take some time to vet the legitimacy of your business in a process called due diligence. For software companies, this may include a technical audit where the buyer, or their diligence agent, tries to understand how your software works under the hood.
As the founder of a technical diligence firm, I’ve helped 100s of buyers vet SaaS businesses before acquiring them. I thought you might like to know what my team, and buyers, look for when doing technical diligence on a SaaS startup so you might better prepared to pass it (without headaches).
Why Learn About Technical Diligence?
For some transactions, acquisition due diligence can become a real nightmare. Cross those T’s and dot these I’s. Pull every customer contract you’ve ever signed. And you do know where those tax returns are from three years ago, right?
You’re dealing with lawyers, accountants, and investors. All of whom are trying to dig through information you haven’t needed since WeWork was still a unicorn.
And your business doesn’t stop running just because someone wants to buy it. The last thing you want when trying to save an enterprise account from churning is me asking for a “system architecture diagram”. The hope is, with this guide in hand, you’ll be able to save yourself headaches later.
All of the advice below exists on a spectrum. Some of the criteria I mention will make sense for your business’s level of sophistication and some won’t. Transaction size plays a role, too: the larger the deal, the more likely the buyer will want to check more boxes. If the buyer has retained a technical due diligence firm, it’ll likely have its checklist of items too, but if you follow the advice here, you’ll be well prepared for any level of diligence.
Move Fast Without Breaking Things
In the Before Times, when software was shrink-wrapped and didn’t come in browsers, getting a new software release out to users was difficult. Today the infrastructure has matured, and deploying new or updated software can be as easy as pushing a button.
As a technical diligence team, we want to understand how often your software is deployed and what that process is like. Do you have a process that runs your automated tests to ensure everything is still working?
A general rule of thumb for most SaaS businesses: the more often you can deploy, the better. It’s good to have the systems and infrastructure in place to deploy with ease, even if you don’t regularly exercise this capability.
Key takeaways:
- Note your deployment cadence and strategy, including the technical components involved in a build of the software.
- Streamline your deployment process to make it as easy as possible.
Don’t Ignore “The Bus Factor”
The Bus Factor is a metaphor we use in software to refer to the risk of losing team members with vital information. The gist: if a core team member was hit by a bus tomorrow, could their work be reliably taken over? Grim, I know. But in reality, lots of knowledge exists in people’s heads only.
At first, a buyer will be the least knowledgeable person in the enterprise, meaning they have the least leverage when it comes to key-person risk. To mitigate this, one of the things we look for is technical documentation. In addition to being a hedge against centralized knowledge, it speeds up the diligence process by making it easier to glance at the system without needing to read every line of code. And if the buyer has ambitious product plans, they may want to add new talent to the team.
Key takeaways:
- Gather all useful technical documentation into a centralized place where it’s easy to find.
- If you don’t already have one, have your development team create an onboarding manual detailing how a new developer would get up to speed. This should include everything from big-picture architecture to spinning up a local development environment.
Watch Those Bugs
Your team just shipped a major release. Everyone is celebrating. Then the bug reports start pouring in. A screen of the app stops working. The onboarding flow isn’t sending emails. Your developers won’t stop talking about the increase in queue depth, and you’re not 100 percent sure what that means but can tell that it’s not good.
It’s a known fact: all software has bugs. Unfortunately, we live in the real world and can’t squash every single bug as soon as it crops up. We have constraints and product roadmaps. But for the love of all that is sacred, please log your bugs in a tracker with descriptions and reproducible steps.
Many automated bug tools integrate directly with your source code. If none work for your business, any ticket tracker software (e.g. Trello, Jira, Notion) will do. What’s most important is that you get something and use it.
Key takeaways:
- Keeping a record of bugs demonstrates sophistication in your product process and assures a buyer that you’re on top of things.
- If available, use bug-tracking software that can automatically notify of unexpected user interactions. Ideally, this would also include the steps to reproduce.
Leave Code Breadcrumbs
Software evolves. Business requirements change. Customers want new things. Bugs get fixed. All of these changes impact your codebase and help form a narrative. Modern best practices dictate using a version control system to track changes to your source code. This is beneficial for a few reasons:
- You can track who changed what and when they did it. If I want to understand which files were modified to implement a feature, I’ll review the source control log.
- There are multiple copies of the source code files available, just in case changes get lost. Usually, software teams synchronize their file changes via a centralized service like Github or Gitlab.
In practice, most development teams are already doing this, so it should be an easy one to check off.
Key takeaways:
- Make sure you track code changes in a version control system, preferably Git. The sooner you can start tracking, the better.
Lock It Down
Security is a huge topic and a full detailed accounting of all best practices is beyond the scope of this post. That said, there are some extremely low-hanging fruit that you should address, most of them revolving around process.
Keeping Secrets
How does your team store credentials? Are there extremely sensitive secrets floating around in Slack channels? Has someone accidentally copied the database password into source control? You’ll want to make sure this kind of stuff is locked down. For sharing secrets use a shared password manager or something that supports encrypted messages like Keybase.
Confidential Access
One of the core principles of good security is the privilege of least access – a person/program should have all of the information it needs to do its job, but nothing more. In practice, this means making sure team members don’t have unnecessary access or privileges. Does a customer support team member need the production database credentials? No.
Maintaining the Software Supply Chain
In late 2021 a security vulnerability of epic proportions was disclosed. Code-named “Log4Shell”, it allowed malicious attackers to execute arbitrary code by manipulating log messages. The biggest Internet companies in the world were affected, including Amazon and Google. Fortunately, the open-source community was able to quickly release patches that mitigated the exploit. Unfortunately, there are still vulnerable systems in the wild that haven’t been updated. Staying on top of your application’s dependencies and keeping them up-to-date is important in building a robust security program.
Key takeaways:
- Use secure systems to manage and pass around credentials. Perform an audit to make sure no secrets are out in the open.
- Keep the principle of least privilege in mind, limiting access to systems when not strictly necessary.
- Establish a dependency management program to stay ahead of crucial security updates. As an example, see Github’s Dependabot system.
Remember Reliability
Database Insurance
Most applications use a database of some sort, whether it’s relational or a NoSQL store. One of the biggest risk factors we look for during diligence is whether there are recent database snapshots available and how often those snapshots are taken. Backups are like insurance. You hope you never have to use them, but it’s really nice that they’re there when you need them.
Incident Reports
It’s common for applications to experience downtime of some sort. When that downtime is significant and has a material impact on the business, creating an incident report, or postmortem, is important. Ideally, this document builds a root-cause analysis of the downtime and suggests adjustments to prevent the same kind of problem in the future. Having a list of the major outages over the past year will give a prospective buyer the peace of mind that you run a proactive organization.
Key takeaways:
- Make sure your databases are automatically backed up.
- Keep a list of any service outages and subsequent remediations put in place. This is a good starter template.
Keep Maintenance In Mind
Technical Debt
Have you, or your team, ever taken a technical shortcut to ship a feature faster? Do you have that one flow in your application that you know is kind of janky but you’ve been deferring fixing? Write this down somewhere. Ideally, it’s on a formal product or technical roadmap with a planned fix, but even a Google Doc will do the trick.
Being upfront with a potential buyer about product deficiencies goes a long way toward building trust and making the transaction smoother. Some pieces of technical debt are more complex than others, so if it’s particularly tricky it’s okay to defer the actual implementation plan.
The Feature Vs Maintenance Split
How much of your development team’s time is spent on maintenance vs feature development? If a lot of the team’s time goes to maintenance, this could indicate underlying code quality or architecture issues. At the same time, it’s good to see that the team pays down technical debt over time. Roughly speaking, the team should spend 10-20 percent of its time on fixing bugs and improving the underlying architecture.
Key takeaways:
- Document any pieces of technical or product debt. If feasible, include a rough implementation or strategy to address it.
- Really complicated technical debt doesn’t need to include a remediation plan but should still be mentioned.
- It’s ideal to see the technical team spending 10-20 percent of their time working on technical improvements.
How Prepared Are You for Technical Diligence?
You’ve just been on a whirlwind tour of some of the most useful things you can do to prep your software company for sale. Despite the breadth of material we’ve covered, there’s still a lot we didn’t get into. There’s scalability, system architecture, automated testing, and maybe the most intriguing of all, infrastructure cost. We’ll have to cover those another time.
Again, the hope is that you can save yourself a lot of headaches by getting ahead of these items early so that, come diligence time, you can say: “Oh yeah, I read a great post on acquire.com that gave me everything I needed”.
Well, maybe it won’t be that easy. But when you’re at the deal table and the only thing standing between you and your victory lap is someone like me pleading to “see your sprint burndown”, I hope this gives you a leg up.
The content on this site is not intended to provide legal, financial, or M&A advice. It is for information purposes only, and any links provided are for your convenience. Please seek the services of an M&A professional before entering into any M&A transaction. It is not Acquire’s intention to solicit or interfere with any established relationship you may have with any M&A professional.
