Due Diligence of custom software applications (Non-SaaS but key to Ops)

August 27, 2024

by a searcher from Oklahoma State University in Wichita, KS, USA

Currently I am in due diligence with a business that serves a large and diversified customer base. They were in market before decent SaaS options were available for their industry so they built their own CRM, Billing, and production tracking software which has been refined over decades. The functionality is impressive. I am in the process of determining whether this propriety software is an asset or a liability. SaaS is not the core business but this software is key to their current operations. If needed, there are viable alternatives that can be fairly quickly integrated but this would result in new costs / reduced cashflow.

Within my advisory group we have access to data scientists and programmers that will review the Seller's technical feedback.

What other questions and requests would you recommend to diligence these custom applications:

1. Architecture diagrams

2. Programing languages or frameworks

3. How are services hosted? (cloud, own servers)

4. How is code deployed and managed (source control)

5. Developers or resources that could be used to support the system

Reply by a professional
from INSEAD in Singapore

Some nuance to your points as well
1. Arch I think is interesting from both the technical pov and the user interface. What actions do staff when undertaking common tasks? How much switching of UI do they do/would they do if you replaced with other system(s)
2. Make sure to ask about both frontend and backend. Database types also interesting but prob less relevant for this stage
4. Check for how biz reqs are captured -> into tech reqs -> into code deployment/mgmt

Reply by a searcher
from University of Arizona in Tucson, AZ, USA

This might be implied by your #5, but how many people do they have maintaining this proprietary software? Is it one person or key team that has done it from the beginning? I've been in situations where one employee is critical for maintaining the code base-- your biggest risk initially could just be that one person leaving the company during the acquisition. From an ops point of view, other questions could be: - how much are the spending yearly on system maintenance? and server hosting, etc. - how much are they spending on refactoring or innovation? Basically - how much is this actually costing them to use vs how much would another system cost to use (not factoring in transition costs).

+20 more replies.

Join the discussion