I just came out of an investors' due diligence audit on the SaaS platform we are building for a client who's raising external investment. Let me tell you, it was a wild ride! Their technical consultant thoroughly went through everything with a fine tooth-comb... It was pretty intense. The good news is that it went well!
In this video, I want to share with you the main items to look out for so you don't have any surprises and you can get ready next time you get an audit from your future investors, for the next unicorn app that you're building.
Let's get to it.
Why do investors need a tech due-diligence?
When you build a digital product, either as a bootstrap business or as part of a growth strategy to launch a new product to new verticals, in most cases, there will come a point where you either need to raise funds to grow, or sell your platform/app entirely and exit.
In both cases, those investors - from private equity firms or at later rounds of venture capital - will want to run a full technical due diligence on the platform architecture against several criteria. This will give them the peace of mind that there is a solid base, that their investment is safe. If they're bringing several millions of dollars or pounds, they'll want to make sure that the actual product that is built is not unstable and it's not going to crash like a deck of cards, or could collapse at any time when you add the next feature, or when you start driving more traffic and more users to it.
However, those finance guys are no tech experts. They usually bring external consultants who specialise in this type of technology - like web applications. They are not necessarily experts in a specific programming language: they will follow the concepts and best practices for digital applications.
Their goal is really to find technical impediments that would negatively impact the growth objectives for the investors.
To that effect, they will be very thorough and look at four main components.
1. Product audit and roadmap
The first one is the product. They will look at the basic features, the end-to-end user journeys, and what else is coming up in your roadmap. They will look at the existing market you are attracting, but more importantly, the potential addressable market for growth.
This means they're going to have to look at rolling out your product in other verticals or whitelabelling it to resell the same service to partners under different brands for example. This is key: as we said, most of the time they will be looking for growth.
2. Source code maintainability
The second point would be source code audit, looking at the development tools that you are using and the repository of the source code. They will be looking for automated test coverage, how the different models and controllers are structured, the database format... as well as how you monitor the performance to try and identify potential bottlenecks when your traffic increases 5 or 10-fold.
They will also be looking for documentation to share knowledge and onboard new team members, so you don't get stuck when one specific developer resigns and takes all the knowledge away.
And finally, they'll make sure the code is written to a maintainable way and that there is no legacy issue. In the developer community, we talk about "spaghetti code" where everything is disorganised and you cannot do anything with it! So that's one thing to plan well from the beginning.
3. Hosting architecture for scale
The third point is the hosting architecture. In most cases these days, a digital app would be hosted in the cloud. They'll be auditing services that you use, the type of servers, database caching, queues, email system, and so on. Similar to the code audit, they will be focusing their attention on performance and redundancy. This will help them identify the potential points of failure and how the architecture can scale without major refactoring.
One of the main things to be clear about with the auditor early on, is the stage of your delivery, the stage that you're at with your product. Are you still building the MVP, or do you have all the features you need to scale and take it global? That will impact some of your decisions:
There is no point implementing a fully distributed architecture if you're still at the MVP stage trying to validate the concept.
4. Processes for security & compliance
The final and fourth point is your processes. The auditor will be looking at the compliance against the data privacy regulations in your region. They will also be looking at the security elements of your hosting, such as penetration testing and disaster recovery planning. Finally, they will review your development process around agile, regression testing and how you support your application with SLAs. If you're planning on scaling globally, you might need to upgrade your team and your processes to cover 24/7 support.
In our case, the application we built for this client was a custom-built application. However, one of the risky areas that I would want to explore more in a future video is how you approach this type of audit if you have built your MVP with a no-code or low-code technology... You usually would have less control over some of those elements and you might have to refactor some of it to scale.
Most of the time, the items I shared today will not necessarily make or break a potential investment deal. However, it may impact the level of commitment or paint a more realistic picture to the investors about the state of your technical platform, and where you can take it.
This is why it's important to take all of that very seriously. If you're considering taking your web application to the next level and need a reliable partner to ensure smooth technical audits on your platform, or tweak your processes so you can demonstrate that it's ready to scale, just get in touch. Don't forget to subscribe to my YouTube channel and follow me on Twitter to keep learning with me and grow your career in digital.
Until next time, stay safe and see you soon.
