A Due Diligence Survival Guide: What to Expect (Part 1: Passing Architecture & Structural Product Scrutiny)

This Spend Matters Nexus series on due diligence kicks off Nexus as its own subscription stream apart from PRO content.

The series is a survival guide on the due diligence process for sellers, especially all the areas outside of finance and accounting (though we’ll eventually get to this part of the process). And we hope that acquirers and investors — even seasoned corporate development, PE and venture types — will find it useful as well. We unfortunately know some buyers who could have spared themselves some headaches had they been as anal as we are in many of these areas.

Perhaps the biggest challenge that executives going through a fund-raising or transaction process face is that they are not adequately prepared for all the curveballs — many of the Astros batters facing the Nationals Stephen Strasburg’s recent loopers come to mind — that might get tossed their way in the due diligence process.

There are so many areas that investors and acquirers might decide to take an extra look at that even world-class “hitters” might not see them coming. And even those who think they are prepared for all the pitches might not fully anticipate the twists and turns the ball might take just before it hits the strike zone (we’ll stop with the baseball analogies, but with one of us coming from the North Side of Chicago, we’re empathetically giddy about our friends in Washington being able to claim victory in the World Series for the first time, turning around what initially looked to be a modest season).

The 2019 baseball Fall Classic aside, fully preparing for diligence is about practice (a topic we’ll explore later in this Nexus series), and it’s one that we ideally recommend companies rehearse — even though few will be prepared from “regular season” play alone at the level that ideally they should be at. Regardless, even those that do not practice sufficiently will stand to benefit from a comprehensive checklist about what to expect.

In Part 1 of our series, we’ll start first with an overall list of areas to consider from a diligence checklist perspective. Then we’ll immediately dive into what to expect around architecture and structural product diligence. (Warning: This is deep!) In the weeks to come, we’ll crawl out of the technology weeds as our exploration continues.

And of course throughout this Nexus series, we’ll aim to put a unique spin on the topic for procurement, finance and supply chain software companies, as these are the software segments we’re most experienced in scrutinizing — and occasionally preparing or dressing up for a process.

Let’s begin.

Jason Busch serves as Managing Director of Spend Matters Nexus, a membership, research and advisory organization serving technology acquirers (private equity, corporate development, etc.) and CEOs in the procurement and finance solutions marketplace (including contract management, B2B marketplaces/connectivity, indirect procurement, services procurement, direct procurement, commodity management, payment, trade financing, GRC/third-party management and related adjacent sectors).

Making a List

Transaction due diligence is quite invasive at the extreme (it might not be so in every case, and venture rounds tend to be much less invasive, at least before the growth capital stages when PE and venture are increasingly converging).

At a minimum, the organization has to analyze and prepare key documentation on all of its operations, including:

• The total addressable market (TAM) and a realistic picture of the company’s market opportunity
• Finance
• Corporate Structure
• Property, Assets & Leases
• Environmental, Regulatory, Health, and related Compliance Concerns
• Legal, Tax & Filing Compliance, & Litigation
• Insurance & Liability
• Partnerships
• Sales & Marketing
• HR, Employment, & Pension / Vacation Liability
• Intellectual Property
• Customer Voice
• Customer Onboarding
• Customer Support
• Market Insights
• Current vs. Potential Go-to-Market Strategies
• Fit for Adjacent Areas
• Benchmark Against Competitors
• Adjacent Areas
• Current and Potential Product Differentiation
• Roadmap and Process
• Development Organization
• IT Infrastructure
• Product

Putting Product and Technology First

In the software space, the most likely reason a company or firm will be interested in an acquisition or investment is because you have unique assets which they believe will continue to deliver on the brand, product and customer promises that got them to where they are — and scale to the next level of growth.

Hence, it is essential for any buyer or investor to insure that the product, and underlying technical infrastructure, is not only ready for a post-close future, but that the target can document all of the materials to eliminate as many potential investment risks as possible.

For the founders and executives, this will involve a lot of documentation, as this goes well beyond the feature/function comparisons that you will be helping marketing with with it comes to customer and industry analyst firm RFIs, demonstrations and research. So how do you do this? Start by addressing each of the areas a technical due diligence team, whether they are doing a forward or reverse due diligence, will look at.

This will include:

• Core Product Architecture
• Technology Stack
• Development Process
• Quality Control Process
• Scalability, Reliability, Redundancy and Backup
• Security and Privacy Support, including Audits & Third-Party Certifications
• Production Environment
• New Customer Instance Provisioning / Onboarding / Integration Capability
• Common Technology Concerns
  • Open Source
  • Key Third-Party Components
  • Technical Debt

Let’s take these elements one by one (we’ll cover the first five today).

We apologize in advance for delving into a technical level of detail quickly here, but it’s essential to be prepared for what folks like us will look for in order to de-risk a buyout or investment.

Core Product Architecture

In terms of your technical architecture, it’s critical to make sure that others understand the blueprint from which you’re developing modular and feature function capability on top of. Shortcuts here can signal to those conducting diligence that the underlying foundation may not support the structure you’re building on top of for the long-term.

We recommend:

• Fully diagraming your core product architecture
• Being prepared to describe it in detail. This is even more important if you are not using a modern 3 or 4 tier M-V-C / M-V-VM-C, client-server, SOA, P2P or other modern web-architecture, or deviate from your primary architecture in any part of the application.
• Also addressing the storage layer and documenting high level data-flow / E-R diagrams that overview your persistence layer as well as detailed E-R diagrams at the table/object level (as a real technical expert will want to do a deep dive to see depth, breadth and the ability to easily expand the schema).
• When documenting and preparing to explain your product architecture, make sure the levels / components are clearly differentiated — and not just represented as such on a diagram because a good technical reviewer will want to walk through the source code repository and dive into random classes in the code base. Here, make sure the purpose of each is clear, and all integration points captured. Also make sure you’ve clearly documented your branching strategy in the repository because a technical reviewer may want to review this as well.

Technology Stack

You will need to articulate your technology stack with extreme clarity. What platform, what languages, what libraries, what versions and why. If the stack is more than a year or two out of date, be prepared to explain why, and, similarly, if you jump on a new stack when it’s less than six months out of the gate, also be prepared to explain why.

Be sure to also generate a list of all open-source components and identify all of the appropriate licenses, and all licensed products. And be sure to know where all of your contracts or agreements for those are!

Let’s double-click on this for a minute, tackling the open source question first. Here, assume (even if it proves a false assumption) that buyers and their advisers and partners will be afraid of open source. We hate to say it, but “big software” has done a great job of convincing finance types that open source is riskier than it really is (even though heavily used open source is more analyzed and stress-tested then most of the software put out by the global software heavyweights).

You’ll also need to show the versions you are using to pass security tests. As such, you will either need to identify and run an accepted full suite of tests against your platform (and share the raw output), solicit a security firm to do the testing for you (and share their report), or find a reputable third party that stress-tests the open-source products of interest on a regular basis.

Next, when it comes to proprietary software you might be using, keep in mind that due diligence reviewers will want to ensure the versions you are using are still supported. You won’t necessarily need to be on the latest version, but technical reviewers will want you on a recent version. Finally, risk and legal reviewers will want to ensure that your contracts, licenses and payments are up to date because this is a key step in de-risking the contractual side of technology components in a transaction.

Development Process

The due diligence team will want to understand the development process from the inception of a product feature to promotion to the production system and delivery to the client. You won’t need to document all of the process, but be sure to clearly articulate the following:

• Process by which a feature/function hits the roadmap
• Process by which a feature/function hits the release
• The methodology used during each release (which is probably some variant of agile)
• The methodology used to assign a feature/function to a team member
• The methodology used for code review after check-in
• The methodology used to mark a release as QA ready

And be sure to document the following:

• The coding standards that are used by the development team
• The code repository structure (and release branch methodology)
• The development organization hierarchy

Quality Control Process

How do you ensure the code is stable, reliable and critical-bug free? What is the code review process? The unit test requirements? How often are they run? Are stress tests run? User acceptance tests?

Document all of this — and be as specific about the process as you can. Smart buyers know (especially in the case of acquisitions requiring integration) that the risks associated with insufficient quality control processes — even those not manifested to date in delayed or buggy releases — will only balloon in the case of post-close product integration and/or scaling up a release schedule and product roadmap.

Scalability, Reliability, Redundancy and Backup

Any investor or buyer is likely investing in growth — so this will mean more users on the platform. Hopefully many, many more. To what extent can the platform scale, and what is the limiting metric? Users? Transactions? Catalog Items? Be sure to know what it is and how much additional hardware would be required to scale and the cost — either in a physical or virtual environment.

Also, be sure to have done some stress testing to demonstrate the reliability of the platform under near-maximum load and have the results ready to share. The platform should support redundancy natively, enable real-time backup for critical data, and back-ups should be tested regularly (and the results documented and ready to share).

Up next: Security and privacy support, production environment, new customer instance provisioning / onboarding / integration and common technology concerns.