Can You Do Technical Due Diligence Without Being a Coder? 

You might be surprised to learn that, yes, you can do technical due diligence without being a coder. Not in every acquisition, but it’s possible in some. Larger acquisitions typically involve more complex tech stacks, but even then, you might learn enough to de-risk your investment.

But to run a SaaS or tech-heavy company, you’ll need a technical person eventually – even to just debug the software or build new features. Assuming you lack the expertise now, however, how much technical due diligence you do alone depends on your appetite for risk. 

If you’re acquiring a small, simple business with a clean codebase and thorough documentation from a collaborative founder, you might go far. But a large company with sprawling, buggy code with countless dependencies on third-party plug-ins or libraries could be overwhelming. 

Even if you inherit the founder’s CTO, due diligence is your responsibility. And the size and complexity of the task will dictate how much technical due diligence you can and should do as a non-technical founder. Get help or only bite off what you can chew. 

To help you conduct technical due diligence without any coding expertise, start with our general guidelines below. It’s not an exhaustive list and always use common sense and your better judgment – or those of technical experts – whenever you’re unsure. 

Talk to the Founder About Their Code

When you’ve reached the due diligence stage of an acquisition, you should’ve built up trust and rapport with the founder. Build on that trust by checking the founder can speak to their code. Start technical due diligence by asking basic questions that verify they know what they’re talking about. 

You’ve probably hired experts in the past without knowing anything about their trade. You might ask a building contractor about their past jobs, disgruntled customers, and so on. Equally, you might not be able to review a company’s code, but you can assess how people feel about it.

If the founder is non-technical, ask to speak to their CTO or lead developer. Ask a series of questions and see how they react. Are they comfortable during the interview? Can they confidently respond to every question? Do their answers match the founder’s? 

Example questions include:

• What is the tech stack?
• Who wrote the code? In-house or outsourced?
• How old is the code?
• Are agreements in place protecting IP?
• Who maintains the code and how?
• What does the software development cycle look like?
• How does code go from idea to production?

Don’t focus so much on verifying the content of their answers (unless you’re capable of doing so) but on how they answer. Do they know what they’re talking about? Are their answers brief and vague or long and detailed? Use your instincts to verify their claims, get a feel for the founder’s approach to technology, and note any reservations for later. 

Can You Use the Technology or Find Someone Who Can?

“What is the tech stack?” is one of the most important questions you’ll ask during technical due diligence.

It can be helpful to think of a “tech stack” as a suite of technologies the company uses to carry out its business, conceptualized in two parts:

1. A front-end stack, the technology used to develop what users see through a website or application. Think of it as the “chassis” of a car. 

2. A back-end stack, the technology that powers user interactions, processing what users input and returning the correct data. It’s the “engine” of a car. 

Front and back-end technology can be proprietary (built by the company that uses it) or a complement of various third-party applications. Proprietary technology should include operational instructions and documentation just like any other vendor application.  

At the very least, obtain a list of every item of technology the business uses. For example, maybe it runs back-end code on serverless technology like Google Cloud Functions or maybe it still manages servers itself with technology like Amazon’s EC2.

If you plan to retain the tech team when you acquire the business, you might not worry so much about capabilities since you’ll inherit people who know how to use the technology. But if you have to source your own team, consider how that technology impacts recruitment. 

For example, many coding languages go through popularity cycles. Engineers and developers tend to ride these waves as it makes them more desirable hires. But if you inherit a tech stack that’s no longer in vogue, how easily or affordably will you find developers `to maintain it? 

Shadow the Founder from Idea to Production

Writing code is just the first step of the software journey. The second is the process of reviewing, testing, and taking that code live. As a non-technical founder, you might not write software, but you’ll need to understand how to update it – even when someone else makes the changes. 

How does code go from idea to production? Is it automated with the click of a button or is it more complicated? The founder or their technical person should walk you through that process, showing you the tools they use and how they test or QA the code. Smaller startups probably don’t do much QA, but in bigger companies, an internal or external QA team might be responsible for purging bugs from the system. Can you maintain that process?

Start by asking the founder to show you something small, such as changing a word in the product. Let them walk you through that change from beginning to end. Understanding how code gets into production will help you collaborate with the founder’s tech team should they stay on or onboard the right technical person if they don’t.

View the Source Code History

When doing technical due diligence as a non-coder, viewing the source code history will give you a single, verifiable version of the truth. Someone might try to pull the wool over your eyes verbally or selectively sharing data. The source code history, however, tells the real story.

Imagine the founder tells you they’re the only developer. You peek into the source code history and see another name has committed files. Who is that person? Why hasn’t the founder mentioned them? Maybe it’s an innocent mistake, maybe not, but it raises questions.

I recall a buyer once contacted our support team saying a seller didn’t want to give any of the source code history, just a zip file of the codebase. They asked me if that was a red flag. Yes! How can you verify the founder’s story without the source code history? Even read-only access would do.

The source code history tells you so much:

• How old the code is
• Who authored the original
• Who’s been inside the codebase
• Who’s committed what and when

It records everything that’s happened since the code was written. Use it like a ledger of accounts against what the founder has told you. If you find holes in the founder’s story, that could be a red flag and is worth digging deeper or asking for a technical person’s opinion. 

Does the Technology Rely Too Much on Third-Party Libraries?

Due diligence of any type involves scouting for time bombs. What threatens the business’s success or viability? One danger is third-party libraries. While it’s common for companies to rely on these libraries to function, vendors typically sunset libraries made obsolete by something newer or when they decide not to maintain them anymore. 

For example, Google sunsetted Sign In library on March 31 2023 after replacing it with Google Identity. It’s also “phasing out third-party cookies in Chrome in the second half of 2024.” 

If the company you’re acquiring relies heavily on third-party tech, ask the founders or the tech team if they’ve yet to prepare for any major deadlines. You might then insist that the founder completes this work before you acquire the company, perhaps as part of a transition service where the founder stays on for six months or longer after closing day.

If the founder fails to disclose upcoming issues, they could leave you with a broken or dysfunctional product. Updating or replacing libraries is a much bigger job than, say, tweaking pricing or marketing. 

Beware Tech Debt (Big Work for the Future)

Third-party libraries aren’t the only source of trouble. Tech companies can accrue all kinds of technical debt or work to prepare for the future. You probably expect to grow the business you’re acquiring, but scalability isn’t always built into the technology a company uses. Ask the founder if they know of anything about the technology that might prevent the business from scaling. 

In the past, it might have been the company’s physical servers. But in today’s cloud computing world, most tech companies use Google, Amazon, or Microsoft servers. You can’t grow exponentially forever – despite the server space of a giant like Amazon – and even moderate scaling comes with a cost. This only becomes an issue if you really take off, but it’s something to think about and research before you acquire the company.

Your biggest red flag here is third-party dependencies. If you’re pulling data from or relying on a third-party service, it won’t always scale with you. Say you pull geolocation data from a small service that provides restaurant addresses in a city. If you suddenly scale by hundreds of thousands of users, will you still be able to piggyback off that service or will it break, withdraw, or throttle your usage?

Ensure that during due diligence the founder can reassure you that the tech infrastructure can scale and that any third-party dependencies will scale with you. 

Who Can Help You Conduct Technical Due Diligence?

The obvious answer to who can help you conduct technical due diligence is someone technical. Where you find that person is another story. You either need to learn how to develop the tech stack you’ve acquired or hire someone to do it for you. But you might need to acquire the business first and this person second, so here are some alternatives. 

Hire a Technical Due Diligence Specialist 

You’ll find services offering technical due diligence online. I’ve never used them before, so can’t speak to their efficacy. Some appear to be offshoots of software business consultancies, while others are services offered by freelancers or fractional CTOs. 

It might seem sensible to hire a third-party service to do your technical due diligence, but ensure you evaluate the quality of their work and reputation. Read reviews and view sample technical due diligence reports to establish their credibility. Ask how they can make the technical due diligence process easier for you, a non-technical entrepreneur. 

Ask a Technical Colleague or Friend to Help You

With smaller acquisitions, you might ask a friend or someone in your professional network to help. This is cheaper, usually free, but the question is whether they’ll do as deep or as thorough an analysis as someone paid to do the work no one wants to do. 

Say you have a friend who’s a building contractor and you ask them to inspect your house. Will they crawl under the floors, fighting spiders, and climb into the attic, balancing on beams, to evaluate every nook and cranny? Or will they give it a quick once-over and say everything looks fine and suggest you fix anything that goes wrong later?

If you can trust your friend and they’re committed to doing technical due diligence right, you might get away with doing this on smaller acquisitions. On larger deals, hire a specialist who does technical due diligence for a living and who can spot subtle problems quickly and help you mitigate risk. 

Should You Acquire a Tech Business If You Can’t Code?

I have mixed feelings about acquiring a tech business when you can’t code. My philosophy is anyone can code. It’s not advanced mathematics or quantum physics where you need years of study just to become proficient. All the information you need exists online. Everyone is different, but I’d say learning a programming language, at least becoming good enough to update or maintain a codebase, probably won’t take you more than three to six months of full-time study. 

That said, as someone comfortable in multiple languages, I probably have a rose-tinted view. Not everyone finds coding interesting and maybe you’ll do better spending time on the things you excel at and enjoy doing.

As I wrote at the beginning, doing technical due diligence without being a coder comes down to your appetite for risk. What’s the worst thing that could happen and could you survive it? Do you have the cash reserves to urgently hire a developer to correct mistakes you missed during technical due diligence?

Acquiring small tech businesses to cut your teeth on as a novice developer can be fun and exciting if you have the time (and inclination) for it. Especially if you know someone who can help you out in a pinch if you get stuck. 

But if you acquire a six or seven-figure SaaS, one that’s fairly unique and relies on multiple technologies, the risk of something going wrong is higher – and might require more work or expertise than those of any friend you can call upon for help. 

Technical due diligence might appear frightening if you don’t know how to code. It feels like learning a new language because that’s kind of what it is. But anyone can do it if they want to learn. And you can infer a lot about a startup’s technology by observing how a founder or CTO talks about it, its documentation, history, and how logically it’s designed.

If you’re unsure of whether to conduct technical due diligence yourself, start with the advice above and then decide whether it’s worth hiring an expert to put your mind at ease. 

---

The content on this site is not intended to provide legal, financial or M&A advice. It is for information purposes only, and any links provided are for your convenience. Please seek the services of an M&A professional before entering into any M&A transaction. It is not Acquire’s intention to solicit or interfere with any established relationship you may have with any M&A professional.