How to assess software quality of a SaaS Company?
May 26, 2021
by a searcher in Madrid, Spain
Hi all,
We are close to signing an LOI with a SaaS company in Europe, and we would like to understand how other searchers have approached the problem on how to ensure the software quality of a SaaS company.
We are planning to do the following:
+ Technical DD: hiring a firm to perform a technical DD (scalability, technical debt,...) and interview the team
+ Interviews to experts from an expert network (e.g, GLG, AlphaSights) to understand how does this software compare vs. its competitors
Is there something extra that you have done? Any tips?
from Northwestern University in Bozeman, MT, USA
Does the software (as it is built and being leveraged by existing customers today),
1) Solve a real, pressing, well-defined, problem that your customers have? (this should be supported by qualitative research)
2) Does the problem your customer has hurt bad enough that end-users are looking for solutions to solve that problem and are willing to pay money just to get something a little better than their current tool.
To confirm that you have true product-market fit, you should be able to find or ask the seller to produce- (Trust but verify if this is coming from the seller) enough examples of current customer testimonials communicating this problem that they solved or were looking to solve and that they solved it with your target acquisition firm's SaaS solution. If you can't get access to this, find direct competitors in the marketplace who offer similar products you can look to confirm the business problem is clearly identified and shared by many end-users.
Once you confirm the software, (as-built today, not as a roadmap item that the engineering team will eventually get to building into the product) solves a very specific and well-defined/ easily understood problem for a very specific and well defined Ideal Customer Profile, then you can use some quick TAM/SAM/SOM market analysis to determine how many customers the company already has with this problem versus how many more people are out there in the world with unmet needs your software can solve.
If any of this stuff around the problem that they are trying to solve is not clearly defined or feels inconsistent with the reason that current/past customers have purchased or are using the SaaS tool currently, I would run the other way.
from Columbia University in New York, NY, USA
I am going to play with the analogy of an operating restaurant (first time, so let's see how it goes).
1) Fundamentals perspective: The food has to taste good, the chefs have to compose it with health and safety in mind. >> In a SasS context. High code quality, good community standards, framework is utilized correctly, developers have done their work in a safe and conventional manner.
2) Secondary perspective: It's not enough to operate a kitchen. You have to get it out to customers. They have to sit down at clean tables. The wait staff needs to be polite and understanding. If you have delivery or pickup, that requires additional infrastructure. Obviously, you'll need a way to collect payment. >> In a SaaS context. Robust DevOps in place. Scalable server & deployment choices. Customer support infrastructure. Ability to handle outages. Ability to rollback deployments. CI / CD infrastructure. Issue management systems. I could go on...
It's in #2 where I see a lot of TDD fail to address issues. It's one thing to receive great code quality, but have an application with no infrastructure for deployment or runtime monitoring. I think I would prefer to take a small bath on the code knowing the other infrastructure suits my needs for continuous movement.
In most cases. You, the acquiring firm, is buying an asset that you want to grow and change. Unless you are putting it on autopilot for the next decade, #2 is going to be a relevant part of the due diligence.