How Your Tech Can Help You or Hurt You During a SaaS Exit

When you sell a SaaS business what you’re typically selling is the code base that runs your product, the cash flow from your current customers, and potential future growth. (For simplicity’s sake, we’re not going to get into the difference between an asset purchase agreement sale and a stock sale in this post! Whichever type of sale you’re pursuing, technical review will be part of it if you’re selling a SaaS).

So the code base of your product is obviously a key part of what a potential buyer like SureSwift will review before they make you an offer.

Since we started buying SaaS businesses 2015, we’ve reviewed thousands of potential acquisitions. Based on all of those reviews, here’s everything we think Founders should know about technical due diligence before a sale, including what kinds of questions to expect from a buyer, what buyers might see as red lights or green lights in your tech, and what to expect during a transition when you find the right buyer.

What kinds of questions should you expect during technical due diligence?

During a conversation with a serious potential buyer, you should expect to cover the basics of your tech stack and infrastructure, how ready your product is to scale, as well as questions about data storage and compliance.

These are examples of questions that SureSwift asks Founders during a technical review:

Architecture and scalability

• Can you give an overview of your tech stack, infrastructure, and how components are pieced together?
• Can you describe which data stores you use and what's stored in each of them?
• Can you describe your deployment process and how often you deploy?
• How is your development team structured? How long have they been working on the product?
• How would you onboard a new developer to the team?
• What features are you currently working on?
• Knowing what you know today, is there anything you would change about how the product is built?
• What feature would you refactor if time and money weren’t an issue?
• Have you had any downtime in the last year? If so, how did you communicate the issue to your customers and how did you resolve the issue?
• Could your business double tomorrow? What would break?

Compliance

• What type of personal or confidential data are you collecting from your customers?
• Where is this data stored (if cloud, state which location e.g. AWS-East1)?
• How is the data secured (list controls)?
• What security measures do you have in place to protect data?
• Have you been asked to delete a customer's data? How often? Were you able to comply within 30 days?
• Do you have any formal security certifications?
• Are you compliant with GDPR? Why do you believe so?
• Are you compliant with CCPA? Why do you believe so?

This might seem like a lot of questions, and there might even be a few in this list that make you sweat a little. You shouldn’t let that discourage you from a sale. Potential buyers of bootstrapped SaaS businesses know they’ll need to maintain and improve code over time. What we — and other buyers — are trying to understand during technical review is how prepared we would be to replace your technical knowledge after a sale.

Tech red lights that can stop a sale

There are some major red lights on the tech side that can stop a SaaS sale in its tracks. Here are some of the most typical ones we see.

Learning project vs. business

Developers often want to try out a new language or platform as a learning project. And that’s great for personal development, but that’s a learning project, not a business.

Learning a new language vs. using one you’re already familiar with usually means a fair amount of technical debt or refactoring for a future owner, and that’s going to be a red light for many buyers. (An exception to that could be selling a side project for a lower multiple to a smaller buyer looking for a project of their own.)

If you know you want to run a project as a profitable business and you think you may want to sell it someday, pick a language and technologies you already know. If you want to learn something new and make some side income from it, that’s also totally fine if that’s your goal — just know that it may not be possible to sell that project down the road for a significant amount of money. Or it might be smart to plan to refactor and improve the tech stack (ideally with experienced collaborators) before you look to sell.

Undocumented and unclear code

Often you’ll have signed a Letter of Intent (LOI) with a potential buyer before you let them really dive into your code. At this stage, buyers will be taking a close look at how your code is structured, documented, and organized.

A new buyer will always have to make some adjustments to maintain your code, but if it's too disorganized and all over the place, they’re likely to pass because it’s going to be too hard to maintain that code without the Founder to know how to fix things and efficiently implement new features.

Violating terms of service, or integrating with other services in a non-standard way

Almost all SaaS products have some integrations with other services, but it’s a major red light if you’re violating the terms of service of any of those third-party companies. For example, if you need to sync with Shopify, but how you do it is different than 99.9% of other Shopify apps, that’s not going to look great to a buyer. Or if you integrate with Facebook, and you’re violating any of their terms of service, that’s going to be an issue that a new owner probably won’t want to take on.

Outsourcing all development to a third-party agency

If you’re thinking of selling your SaaS and you want to outsource development, it’s generally better to hire your own part- or full-time developer than to outsource everything to an agency. That’s because an agency could decide that they don't want to work with a new owner, or they could change pricing significantly and that would put the entire dev team at risk for a new owner.

It’s not always the case, but an outsourced agency can also sometimes indicate that development is happening by the fastest and cheapest route possible vs. the highest quality. And finally, there will probably also be concerns about how knowledge transfer will take place since the agency isn’t signing your sales docs or under contract to provide anything to a new owner.

Massively outdated versions of anything

You don’t need to be running the latest and greatest version of everything, and having some technical debt and required updates on your roadmap is completely normal. But if you’re running off a version of something from the early aughts, it’s a pretty clear signal to buyers that you haven’t been spending a lot of time maintaining your code.

Too much tech debt

If you’re using open-source software,  things are changing all the time, and you’re naturally going to have some technical debt. So when would a buyer potentially say it’s “too much?”

From our perspective, even companies that are growing really fast need to take a step back at some point and reevaluate and refactor parts of their code base — particularly before they build more on top of it.

If you go down the path of building one thing on top of another on top of another and you never take time to think about code quality, at some point development is going to become too difficult and your product will be too hard to maintain and test.

If you’re in the boat of having a well-maintained code base, and maybe your front-end is written in AngularJS and needs to be updated to the latest Angular, that kind of upgrade path is clearer to a new buyer.

Big dependencies on small players

In the MVP phase of a business, you often piece together anything that’s available to get your product out the door and get your first paying customers. That’s totally normal. But heading into a sale, you don’t want your business to be too dependent on a piece of software that may be deprecated or is maintained by one person (and that also could mean a specialist hire is needed to replace knowledge in that tool set, which isn’t ideal).

Unresolved legal issues

This one’s fairly unusual, but if you’re dealing with any sort of lawsuit involving the Intellectual Property of your code base — by a former employer, Co-Founder, or employee — that’s not going to be something a new owner wants to take on.

Tech green lights for a sale

On the flip side there are lots of things on the technical side that can make a sale much smoother. Here are some of the top green lights we look for when we’re buying a SaaS.

Well-documented code and architecture

A Founder that can confidently and easily walk a buyer through how their product is built from a technical perspective and has documentation at the ready is going to have a much quicker, and smoother sale process.

Test coverage

Having a testing suite in place is also a major plus during a sale. It’s a signal to buyers that they’ll be able to make changes to an application in the future and rely on existing tests to make sure they’re not breaking anything major, or causing issues for customers.

If your product is more mature, you’ve taken time to improve your code

We’ve bought several SaaS businesses that have only been around for two years at the time of sale, and obviously we don’t expect a business at that stage to have gone through a lot of code refactoring.

But when we look at a product that’s been around for years, seeing that the Founders and/or their dev team have thought about how to scale or have cleaned up a lot of tech debt is a really positive sign that things are going to be in good shape from a code perspective. It says that a team has invested some time to sit down and think about how to make it better, not just how to keep up with growth without breaking.

Future growth potential

We’ve covered technical reviews from a really general perspective here, but one thing worth mentioning is that tech reviews are never happening in isolation. What a new buyer is willing to take on really depends on how much potential that business has. So while tech is a huge part of a sale, it’s not the only part.

At the end of the day, tech is a huge part of a SaaS sale

You probably knew that before reading this post, but hopefully we helped you understand a bit more of what a potential buyer is looking at when you’re going through tech due diligence and what you can do to make your listing and sales process smoother on this front.

If you’re thinking about selling your SaaS and have questions, send us a message. We're always on the lookout for the next great addition to our portfolio.