Ajay Sridharan

One of the biggest hurdles to buying a software as a service (SaaS) company is that, to some extent, you have to do it driving blind.

No matter how cooperative the seller is and how many snippets of code they share, no small business is going to reveal their entire codebase to you before you fork over the cash.

That means the technical due diligence you perform on that software—i.e. checking for bugs, seeing how well the thing is built, how easy or difficult it will be to add features, how much you’ll have to pay a developer rebuild the thing—will involve some amount of guesswork.

But that doesn’t mean you have to leave technical due diligence to chance, especially if you know what you’re looking for.

Technical debt: an introduction

When we do technical due diligence, we’re looking for tech debt. Pioneering developer Ward Cunningham came up with this analogy to explain all of the refactoring he was doing on a piece of software to his non-technical boss.

Refactoring is what you do when you rebuild and clean up a piece of code, knowing what you know now, without changing its outputs. (“Figure out what it should have been, and you make it that,” as Cunningham puts it.)

It can be difficult to justify spending money on rebuilding something without changing the way it (superficially) works, especially to someone non-technical. Because he was working on financial software at the time, Cunningham explained it in financial terms instead.

If you don’t refactor now, you’re going to have problems later—updates will take longer, new features will get more expensive to build, life will get harder. You’re going to start paying interest on all that work you’ve been putting off.

Continuously rushing updates out the door and tacking new features onto a piece of software without refactoring is like borrowing money without planning on paying it back. You always have to pay it back.

Technical debt is what we’re looking for when we do technical due diligence. How much you find can mean the difference between a seamless acquisition and months of rebuilding.

Gaining the buyer’s trust

Sellers are terrified of getting X-rayed by potential buyers: it’s time-consuming and distracts from their regular work, because they’re afraid of giving away their secret sauce, and also because like you, they’re afraid it might unearth some embarrassing flaw in their product.

You can’t perform due diligence properly if the seller is anxious—they won’t be forthcoming about any potential problems, they’ll be less transparent, and they’ll also be less likely to go through with the sale. The best way to avoid this is to build __trust__.

MEET FACE TO FACE IF YOU CAN

Much like you’d have coffee with someone before going into business with them or going on a second date, meeting face to face lets you instantly develop a rapport with a seller.

If you can’t meet in person, hop onto a Zoom call and introduce yourself. Ask them about any concerns they have, and do what you can to put them at ease. Reassure them that you’re not there to shake them down for information—you just want to learn more about how their software works.

KEEP THINGS SIMPLE AND LOW-STRESS

Warren Buffet is famous for his one-page contracts and his low-stress method of acquiring businesses. If he looks at your financial statements and likes what he sees, he’ll buy, simple as that.

This works not just because it removes a lot of friction, but also because it builds trust.

Poking and prodding too much into someone’s business does the opposite: it signals suspicion and puts the seller on edge.

By all means, do your due diligence, but try not to put the seller under a microscope either. If you’re worried about a problem in the product, ask the seller first instead of trying to dig it up yourself.

The technical due diligence walkthrough: a checklist

When we did technical due diligence on First Officer, a Stripe analytics tool we acquired, we were essentially trying to figure out how the founder, Jaana, had built the product.

Because you’re only looking at a codebase a few snippets at a time and asking fairly general questions about the technical choices the business has made, doing a technical walkthrough is as much an art as it is a science. You need to infer a bunch of things based on what you see.

What do they say about the way this software was built? What do they say about the habits of the person who built it? How much of this are you going to have to clean up/rebuild when the purchase goes through?

PRE-WALKTHROUGH

Sign up for the SaaS tool you’re inspecting first and see what you can figure out about the way it works from the outside. You’d be surprised by how much a talented developer can learn just by using Chrome’s Developer Tools.

ASK FOR SOME CODE

What does good code look like? People who write it for a living will tell you that it should read like a story, i.e. should make __sense__. If you can’t follow the story, it’s probably not written very well.

READABILITY

Can you figure out what’s going on in a piece of code just by looking at it? One fundamental building block of readability is naming—i.e. how has the person who built this software labelled everything?

Are all of the variables, functions and classes named meaningfully in a way that’s designed to aid readability? Being a non-technical or beginner might actually help you here. If you can’t make heads or tails of this stuff as a newbie, it might not be well-written code.

TESTING

Has the code been tested at all? If not, that’s probably a red flag. And if yes, does it run when you test it?

ASK FOR DOCUMENTATION

Software development produces a lot of documentation: initial wireframes and sketches, fully fleshed out descriptions of the software architecture, API documentation, metrics that are important to day-to-day operations, etc.

Get your hands on as much of this material as you can—scanning over it is crucial to understanding how this system was built and how it’s evolved over time.

(Note: you’ll probably want someone with at least a bit of technical know-how to help you with at least these first three steps.)

ASK THEM HOW THEY BUILT IT

Why did they make the technical choices that they made? Why that specific programming language or database?

Ask them about the non-technical stuff too, like how long everything took to build and how much everything cost. What’s their process for developing new features? How do they test, deploy and support those features?

ASK ABOUT THIRD-PARTY TOOLS

What other software or services does this SaaS business rely on? Are any parts of it open source? Have they paid for all these tools and are they fully updated? What about the content on the site? You don’t want to buy a business that depends on pirated software or unlicensed images.

If the business relies heavily on web hosting, ask for and analyze the bandwidth and downtime data—is hosting currently reliable, or will you have to upgrade?

Don’t forget IP and licensing

One huge roadblock we ran into when buying FirstOfficer was that the original owner’s Stripe license—which was for businesses based in Europe—was no good in Canada, where we were based. This was especially problematic given the fact that this was a Stripe analytics tool!

Make sure you’re aware of all of the licensing and legal dimensions of the business you’re buying. Double check things like:

INCORPORATION

Is the business properly incorporated or otherwise registered, and do all its licences, tools, hardware, etc. belong to the business, or do they belong to the owner?

INTELLECTUAL PROPERTY

If the software depends on any patents, trademarks or any other form of intellectual property, has the business locked them down? Or will you have to do that yourself?

CONTRACTUAL OBLIGATIONS

Is the business contractually obliged to do anything you might not want to do yourself? To use specific software or tools? Have they honored those obligations?

Keep everything in perspective

People who build software businesses are busy, move fast and sometimes have to make compromises. Dig deep enough and it’s almost inevitable that you’re going to come across some kind of problem when you do your due diligence.

As we mentioned before, the cornerstone of a transparent and successful sale is trust, so keep things in perspective when you find something you don’t like.

Be upfront about any concerns you have. But unless the problems you find are a dealbreaker for you, try to approach the conversation in a constructive way.

Remember that in the end, you’re not trying to critique this business—you’re trying to understand how this person built their business, why they built it the way they did, and how much it’s going to cost you to fix any mistakes they might have made along the way.

This is a big topic

I’ve got more articles coming on this so feel free to subscribe to our mailing list if you want to learn more about technical due diligence. Or if you want to read more about how we bought our first SaaS business, check that out here.