SaaS (“Software as a Service”) is currently one of the most coveted business models today and in general, SaaS businesses tend to face greater competition amongst buyers and often go for higher multiples, and for good reason. After all, good SaaS businesses utilize economies of scale incredibly well, have very low overhead, and build their own intellectual property.
While it’s entirely possible to own and operate a SaaS business without any technical or programming background, it’s always a good idea to understand the basics of software upkeep and deployment and know what to ask, especially when conducting due diligence on a SaaS business. In fact, we routinely ask the questions below (and a lot more) when we conduct due diligence on software and SaaS businesses on behalf of clients, so this is straight out of our playbook.
Where do you store the source code?
The source code is essentially the code that “builds” the software and it’s important to know where it’s stored. Virtually all software businesses today should utilize some form of version control through software such as GitHub or Bitbucket. Essentially, version control software serves as a storage and paper trail for the software’s code so you can see when features were added, bugs were addressed, and how often things have been updated. It’s all there in one place.
There was a time when developers would keep their code on their local machines and release updates and fixes directly from there but it’s an incredibly antiquated process now and highly discouraged. Fortunately, if you’re buying a SaaS business and the software isn’t stored and tracked through proper version control, it’s fairly easy to start doing so when you take over. However, you’ll have no insight into the past and tracking would begin from the day you implement it. For example, if a seller says their software has been on auto-pilot and required no updates for the past six months, that’s easily verifiable with version control software. Without it…well, not so much.
How are features and bugs tracked?
Most software products track open features and bugs through ticketing software such as Jira. This helps them keep track of what was already worked on, what’s currently in development, and what’ll be released in the future, while simultaneously prioritizing between different features and bugs. Just like version control provides a paper trail for the actual code, ticketing systems help you get an understanding of the product roadmap.
Now, if you’re purchasing a SaaS business from a solo founder-engineer, there’s a high chance they won’t have a formalized ticketing process (though some will). Again, this is something you can start to implement when you take over, but you lose the benefit of having insight into the past and having an existing roadmap.
What is the testing and deployment process like?
Most software today is fairly complex with lots of moving pieces, which is why it’s incredibly important to have fundamentally sound testing and deployment processes.
In the best-case scenario, the seller tells you about their large suite of comprehensive unit and regression tests that get automatically kicked off whenever they update the code, as well as the fact that they have a separate QA/UAT environment to test those changes, and lastly, their sophisticated use of Continuous Integration (CI) to push this thoroughly tested code into production with the click of a button. Worst case scenario, the seller tells you they do no testing and hold their breath while manually updating code files in production. Realistically, you’ll get something in between.
The goal is to ensure that there are some sort of processes in place for testing and deployment, which ensures that if and when another developer was to take over, they wouldn’t accidentally destroy everything and set it on fire.
How do you know if something goes wrong in production?
This really helps you understand how aware the owner or developer is about existing issues. It’s easy to pretend a piece of software has no issues if you have no way to track them. Ideally, the software has built-in error logging coupled with alerting or logging through services like Firebase Crashlytics or PaperTrail. Some solo founder-engineers will tell you that they know something is broken in production when a customer emails them about it and that’s not ideal for a number of reasons: It’s reactive instead of proactive and not every issue will show itself to the end-user — but together, these “hidden” issues can pile up and create a larger problem over time.
Unlike the previous items, this one can’t simply be integrated once you take over as it does require knowledge of the codebase and is a bit more tedious. Here’s an example of how this works in pseudocode:
Scenario: User hits refresh button to fetch new data
if (new data is successfully fetched) {
Display new data to user
} else {
Show error to user, log the issue, and alert developer of issue
}If the SaaS business you’re looking at doesn’t have something like this in place — and most solo founder-engineer-built software likely won’t — you can have someone start implementing it post-acquisition if you’d like, but it will take some time. It’s not a huge deal for relatively simple software built by one or two people but does become a bigger issue for large-scale complex software built by a team, especially ones that are deemed as “mission-critical”.
What language and frameworks do you use? Are they up to date?
One of the most important reasons to understand the language and framework a given software is built on is for you to assess the availability of developers for that given language and framework, in case you want to add features or fix bugs in the future. For example, finding a developer who is proficient in Pascal will be a lot tougher than finding one who’s fluent in Python and has experience with Django or Flask frameworks. It’s also important to know if a software is up to date with its language because it may require updates in the future.
When evaluating a SaaS business, there are quite a few technical components to assess and while this isn’t an exhaustive list, it’ll help guide you and the conversation in the right direction. A lot of non-technical buyers sometimes get spooked by SaaS businesses and miss out on incredible opportunities but really, it’s just a matter of asking the right questions and not skimping on the research. Plus, there are plenty of services out there that can help, including our comprehensive Codebase & Tech Stack Analysis service, where a Senior Software Engineer with extensive experience evaluating SaaS business will conduct due diligence on any SaaS business you’re looking to purchase. You can also always get in touch with specific questions — we’re always happy to help!
Whether you choose to conduct due diligence yourself or hire help, we hope this provides you with a bit more confidence and guidance to consider adding SaaS business to your search criteria or portfolio!
