Sherri Hammons
7 Technical Diligence Questions for Non-Techiesmy binary life
Acquisitions of technology companies happen every day and, with each of these, someone has to look under the hood of the technology to see if it’s really worth the price. (You’d never buy a used car without looking under the hood and likely taking it to a mechanic. Imagine spending a billion dollars on something that didn’t work.) I was recently asked by a private equity business person who performs a lot of acquisition activity for Software as a Service (SaaS) solutions if there were 5-10 questions he could ask in a meeting to gather some intel on the robustness of the solution he was considering. He wanted any red flags early, before the technical people needed to get involved. It was a great question and one that gave me pause. He told me his company has the typical 10 – 20 page form that companies fill out with all the salient questions. But despite their efforts on paper, it never really gives him any red flags. However, more often than not, after they purchase the company, the red flags fly. Here’s a simple non-technical example.
Suppose your insurance company asked you to list your home security precautions in order to get a discount rate:
LIST SECURITY PRECAUTIONS: Monitored alarm system, 150 pound Akita, external video camera, motion detection lights
On the surface, this looks pretty good. And you are 100% truthful. What isn’t clear to the insurance company is that you never turn on your alarm system because the dog will trigger it. You haven’t hooked up your video camera to your computer yet, so it’s not really monitoring anything. Your outside motion lights need changing, but you haven’t had time. And, your forgetful spouse often leaves the front door unlocked and the garage door open.
Yikes.
I’ve been performing technical due diligence for around 15 years and it’s a bit of an art form. I normally ask a few questions until I get red flag, then dive deep into that area. Below are the seven questions that equate to many of the red flags I see. It’s not comprehensive, but it’s a start! I know I can get too technical sometimes, so feel free to comment on areas that don’t make sense.
1. Does the solution have some type of functionality for a particular client (or clients) that not all clients have access to and could the solution potentially fail for one client and not all?
What you are looking for
Maintaining multiple sets of functionality for individual clients are very hard to test and maintain and often contain ‘side effects’ that can cause production downtime. Costs are also higher because you must test each path before deploying your software. Think of it as trying to keep one novel with fifty endings up to date as you make changes to the beginning. You could wind up with a mess in one or more of the endings if, say, you killed off a significant character! And, by the way, no SaaS company will ever say they have customized for a client or set of clients. However, many SaaS vendors actually do. If the code can break for a specific set of clients and not everyone else, then you have customization, even if it’s deployed as SaaS. Imagine if everyone using Google had their own, customized version… Or if Coke created a special drink for every one of their millions of clients. Not sustainable.
Lessons Learned
I recently performed some due diligence for a company with an amazing technology stack. However, they did a customization for a particular client. Even though they stated it was one code base and no customizations, they conceded that they could effectively bring down that one client and that they had to test a different work stream specifically for them. That’s a customized application and at some point, it will become cumbersome and costly.
2. Could one or more users be affected if part of the system went down, even though the whole solution continued to be available?
What you are looking for
You want to find out if clients are affected when pieces of the solution become unusable. This is a very common problem that is often overlooked, but can create a terrible user experience. For instance, if when you login, you are “bound” to a particular server and that server fails, you are kicked out. Many companies actually don’t count this as a failure, but the user experience is that the system went down.
A user shouldn’t experience any problems if it is architected well. Google rarely goes down for any user, much less a lot of users. But, it does happen. Good software companies try to make all aspects of a solution redundant, so that any failure won’t result in a user experiencing anything wrong.
Lessons Learned
It’s so common that it shouldn’t make for a bad due diligence analysis, but it does give you insight into how the software is architected. A good answer here will tell you that whoever designed the software was a very experienced architect. I find that often this is reflective of the rest of the system design.
3. Do you have regularly scheduled maintenance windows where the system is unavailable and do you regularly need to use them?
What you are looking for
In a properly architected SaaS solution, there should be zero downtime for upgrades or deployments.
Lessons Learned
This is also very telling of how a system is architected. Check major SaaS companies to see if any of them (Google, Salesforce, Amazon) ever go down. The answer, of course, is no, except for an occasional headline making catastrophic event.
4. How much do you pay for hardware and software as a percentage of revenue and how many clients will that support?
What you are looking for
You’re trying to do a back of the napkin idea of how the system is scaling, as well as see how much costs are involved as it does. The financial guys are looking for complex numbers, such as Total Cost of Ownership. But, I look for a ‘thumb in the air’ cost when in the initial phases of due diligence. This is a little more nuanced from experience, but in general, if costs are high and you know you need to scale (add new customers, add more transactions, etc.) by a certain degree, you can get an idea of how much it will cost moving forward. Generally, SaaS companies have healthy gross margins of around 60-80%. And, they have a smaller CapEx spend of between 5-10%. I would red flag companies that have high dollar hardware (such as Oracle Exadata or HP Titanium) with few customers or transactions.
Certain software languages are also more expensive than others. For example, SAP and PeopleSoft developers are normally more expensive than Java and .NET developers. Buying a lot of add ons can also increase the cost dramatically. Something to watch out for are reporting engines and BI tools, UI frameworks, plugins, and graphics engines. It is not as common now days, but older code can have excessive costs because of these factors.
Lessons Learned
Oftentimes, engineering teams will throw hardware at a problem to mask certain things. Company A threw a huge hardware stack (millions and millions of dollars) at their problems in order to mask poorly designed queries / software. Costs continued to rise at an astronomical rate as the business added customers, almost to the point of bankruptcy.
5. How current is all the software you use and are any ‘end of life’? (Software = operating systems, middleware, databases and the like)
What you are looking for
Sometimes, poor software may be extremely difficult to upgrade. And a poor upgrade strategy can lead to problems later on. If the code and all hardware/software isn’t on at least the current version (or version minus 1), then you will likely run into a migration problem down the line. For example, if the company runs on Oracle 1.0, then run for the hills. Ask for their software versions and also the most current versions and compare. If you find that the company is several versions behind, be afraid.
In some cases, trying to upgrade can cause unrecoverable and catastrophic failures. Another way to look at it is that older technologies (and some that just aren’t available anymore) are extremely costly to maintain because talent is hard to come by. And, if anything is on ‘end of life’, it means it’s not longer supported by the vendor who built it. Finding this should give you a major scare.
Lessons Learned
Company A is on some End of Life technologies that are extremely time consuming and difficult to remove from the system. And, it is nearly impossible to find talent in the area for some of them. So, time to train is expensive and most mainstream developers aren’t interested in learning it.
6. Is the solution a single application (with user interface and data access combined) or does it have multiple layers? If this were a novel, could you move one chapter around easily?
What you are looking for
This one is the most technical in nature. You are trying to figure out more around costs and how efficient the system really is. You are also trying to find security holes. Ask for a picture of it if you can. Here is a busy one, but it shows how server pools could look. (Each of those little computers in the picture could have one to many functional components, such as reporting.)
And here is Google’s File System.
Lessons Learned
Company A has one big monolith of code that is deployed, similar to having a novel with no chapters, paragraphs or page numbers. This causes Company A to have a huge hardware cost because a huge amount of memory (plus larger amounts of disk and CPU) must be deployed as more customers are added, which equates to a huge and unnecessary cost structure. And, when that one giant piece of code fails, lights out for the user. Imagine if you had to repaint your entire house every time you repainted a room… it would be really costly over time.
7. How many help desk/support people do you have and describe how many tickets they handle per day on average?
What you are looking for
The company should have zero support people. Probably not realistic to be fair, but the more technology can handle issues, the better off the company will be in the long run. Technology should be able to capture issues, identify them, contact the person with the issue, then send a problem ticket to a developer to resolve. Service people need not be involved.
Lessons Learned
Try to call someone at Amazon.
Would love feedback on this blog! Thanks!
Sherri
Sherri Hammons 
Great thoughts Sherri, I was working on a DD list and used some of your wording – Thanks. I like they way you think about these issues, if only everyone did the same.
LikeLike