Technical due diligence is the review an investor, an acquirer or a board commissions before a funding round or a sale, to check that a company's software and engineering team can carry the plan the money is for: architecture, security and data protection, code quality, infrastructure, delivery process, documentation, the people it depends on and the licences it is built on. Cloudnonic works on both sides of it. For founders preparing a round, we get the engineering ready so the review is a reading exercise, with documentation produced alongside the build rather than written the week before. For investors and acquirers, we run the assessment as independent senior engineers and report what the platform can and cannot support.
The eight areas an investor's technical advisor goes through, and what each one has to show. The same list is our checklist when we prepare a company and our report structure when we assess one.
Whether the system's structure fits the next three years of the plan: tenancy, service boundaries, the parts that will have to scale, and the record of why it was built this way.
Access control, encryption, audit trails, data residency and consent handling, written down as concepts and matched to the regulation the business operates under.
Readable code with a review process, automated tests that run in the pipeline, and dependencies that are current and scanned.
Who owns the cloud accounts, whether the infrastructure is defined as code, what it costs per month and per customer, and when recovery was last tested and how long it took.
How a change travels from a ticket to production: review, staging, approval, rollback and release cadence, with the evidence that it happens that way.
Architecture decision records, runbooks, onboarding notes and a data model that a new engineer, or a reviewer, can read without a meeting.
What happens when the one engineer who knows the deployment leaves, and whether that knowledge sits in the repository or in a head.
Open-source licences in the dependency tree, ownership of code written by contractors and agencies, and the third-party terms the product depends on.
GoMedicus went from a scoping workshop in January 2025 to a Series A signed in August 2026. When the round was raised, the platform passed a technical due diligence on the documentation the engineering team had produced while building: architecture decisions, security and data-protection concepts, process documentation. Cloudnonic is still the platform's engineering team.
NestJS
Next.js
PostgreSQL
AWS
Terraform
A preparation runs as an embedded engagement: one or two senior engineers inside your repositories, cloud accounts and pipelines for a bounded period, working with whoever currently owns the system, your own team or the agency that built it. We need read access to the code and the infrastructure, an hour with the people who built it, and the plan the round is based on. An assessment for an investor is scoped from the data room, run under NDA and reported to the investor, with the findings shared with the company's team at the end. Everything we see stays under the confidentiality the parties agreed, and we do not assess companies whose engineering we own.
An embedded team · What this prevents: A six-month hiring cycle for a skill you need this quarter, and a vendor that works outside your process and leaves no trace in your repos.
The two engagement models →Chosen per project. We pick what your team can run after us, not what is fashionable.
OpenAPITerraform
GitHub ActionsGitHub ActionsTerraformOpenAPIThe data room opens, nothing is written down, and the team spends the weeks before the round producing architecture diagrams and security policies from memory instead of shipping.
A review that reads as reconstructed, a delayed round, and a team that stopped delivering during the most visible month of the company's life.
Documentation is produced alongside the build: architecture decisions recorded when they are made, security concepts written with the feature, the process documented by the pipeline that runs it. The package is a by-product, not a project.
The deployment, the secrets and the recovery procedure live with one engineer, often a contractor, and the reviewer asks what happens when that person leaves.
A key-person finding that reads as a risk to the whole investment, and a retention bonus negotiated under pressure.
Infrastructure as code, runbooks in the repository, a recovery procedure that has been run in a drill, and a second person who has run it. Key-person risk is an ownership and documentation problem, and we treat it as one.
Security is a document answered for the reviewer rather than a property of the system, and the first code read or penetration test finds the gap between the two.
Findings that need architectural changes while the round is open, and a credibility problem that outlasts the fix.
Access control, audit logging, encryption and data residency are architecture decisions, documented when they are made and demonstrable in the code and the cloud account rather than in a spreadsheet.
The investor's review itself usually takes two to four weeks from data-room access to report. Preparation depends on the state of the documentation: a team that has recorded its decisions needs days to assemble the package, a platform with nothing written down needs four to eight weeks, most of it closing gaps rather than writing. An assessment we run for an investor is typically delivered within three weeks.
Yes, and that is the usual case. We review the code, the infrastructure and the documentation as they are, work with the agency or the engineers who built it where they are still available, and record what we find without rewriting anything for its own sake. The gap list says what is worth fixing before the round and what can wait.
Yes, as independent senior engineers under NDA, with a written report on architecture, security, infrastructure, delivery process and team risk measured against the plan the round is based on. We do not assess companies whose engineering we own; for those we are on the founder's side and say so.
Read access to the repositories and the cloud accounts, the existing documentation however incomplete, the plan or the deck the round is based on, and an hour with the people who built the system. We sign an NDA before any of it.
No. A technical due diligence is broader: it judges whether the whole platform and team can carry the investment plan, and security is one of its eight areas. If the reviewer or the plan calls for a penetration test, we scope one with a specialised partner and include the result in the package.
Every service on this page is delivered with our AI-Native process: specs as the source of truth, agents in the pipeline, and a named engineer signing off at staging.
How we build with AI →