Can technical debt undermine the post-acquisition plan?
Every application contains technical debt. The real issue appears when that debt prevents the buyer from delivering what economically justifies the acquisition. An isolated outdated dependency does not have the same impact as an architecture unable to support the new customers expected in the business plan.
We distinguish annoying debt, structural debt, and work likely to consume a significant part of the post-close roadmap. Findings are connected to their consequences: slower change, required migration, operational risk, key-person dependency, limited capacity, Cloud cost, security, or targeted rewriting.
How do you assess whether the platform can support the growth plan?
A SaaS capacity assessment cannot be reduced to its current user count. We connect architecture, available metrics, databases, asynchronous processing, external dependencies, Cloud costs, and historical incidents.
The goal is to determine what actually happens if the number of customers, data, transactions, or integrations increases significantly. When load tests or usable metrics do not exist, that absence is itself relevant information. We distinguish what is demonstrated, plausible, still to test, or likely to require change before the expected growth.
The review can draw on infrastructure and operations when availability, deployments, monitoring, backups, or operating costs condition the acquisition scenario.
What should be checked across Cloud infrastructure and operating costs?
A SaaS can be functional while its cost structure deteriorates as it grows. We review infrastructure components and, when available, consumption trends that help explain the product’s economics.
The question is not only today’s AWS or Azure bill. We need to understand which costs vary with customer count, which resources are fixed, which commitments exist, and which architectures would become expensive at scale.
An oversized cluster may be optimizable. An architecture where every new customer requires a significant dedicated environment may represent a more structural economic issue. The Cloud security audit can deepen the review of accounts, IAM, networking, data, secrets, workloads, logs, backups, and pipelines without duplicating that entire review here.
How do you review security and data handling before an acquisition?
An acquirer takes over not only code but also how the product protects and handles data. The review makes authentication, authorization, secrets, administrator accounts, backups, encryption where used, logging, environments, and main exposed surfaces understandable.
We also assess whether the team can explain what data is actually stored, where it lives, who can access it, and how it is deleted or restored. Compliance or certification claims can be compared with available technical evidence, but Koragence does not issue a legal or regulatory certification.
GDPR, contractual, or sector-specific points should be reviewed with the relevant advisors. The technical review identifies observable elements and scope limits, but it does not replace legal advice.
How do you review software dependencies and licenses?
A modern SaaS relies on open-source libraries, APIs, Cloud services, commercial components, payment systems, authentication, and other third-party software. We identify dependencies that may affect operation, cost, or maintainability.
For open-source components, we can inventory declared or technically detectable licenses and flag areas requiring deeper review. The technical review identifies components and signals, but it does not provide legal advice on license validity or intellectual property ownership.
How do you verify that the seller really controls a transferable technical asset?
Technical ownership is not limited to having a Git repository. The product may depend on personal Cloud accounts, a domain registered by a provider, a SaaS tool managed by a former freelancer, certificates, keys, or assets the target does not directly control.
We review the operational control chain: repository, Cloud, DNS, domains, third-party accounts, CI/CD, databases, backups, monitoring, and critical access. The goal is to determine whether the asset can actually be transferred and operated after the transaction without uncontrolled external dependency.
IP assignments, provider contracts, and other legal matters must be reviewed separately by the transaction’s legal advisors.
Why is the engineering organization part of technical due diligence?
The technical value of a product is not located only in the repository. A complex architecture can be well controlled when several people understand it, procedures are documented, and operations can be taken over.
Conversely, a sound codebase can become risky when one person owns the access, knows the deployment, understands billing, and can restore production. We review knowledge concentration, responsibilities, replaceability, documentation, and decision-making without conducting an individual HR assessment.
How do you assess the team’s actual delivery capacity?
An ambitious roadmap has limited value if the product can only be shipped rarely or with a high regression rate. When available, we review Git history, reviews, tests, CI/CD, environments, releases, incidents, and backlog organization.
The question is simple: is the future delivery speed assumed by the investment thesis consistent with the observed delivery capacity? A roadmap of thirty features is not proof. We look for repeatable signals: cadence, automation, release control, and troubleshooting ability.
Should a SaaS’s AI features be reviewed?
Yes when they are a significant part of the product or its value proposition. The review distinguishes what belongs to the target from what depends on external providers, without treating third-party model use as automatically problematic.
Depending on the context, we need to understand provider dependency, usage cost, data sent to models, fallback mechanisms, reproducibility, monitoring, and the genuinely proprietary part of the solution.
What role do incidents and customer support play?
The repository does not tell the whole product story. Incidents, support tickets, and recurring problems often reveal where architecture, UX, performance, or operations already create operational cost.
When data is available and authorized, we connect technical findings to operational reality. A complex module becomes more significant when it also generates a meaningful share of incidents, tickets, or manual interventions.
What is the difference between technical due diligence and a code review?
A code review mainly examines the quality and behavior of a codebase. Technical due diligence answers a broader question: what is the buyer actually taking over, and is the technology consistent with what the buyer plans to do with it?
It therefore covers architecture, infrastructure, security, data, deployment, providers, team, access, dependencies, and takeover readiness. Code remains essential evidence, but it is only one part of the technical asset.
What is the difference from Koragence’s SaaS audit?
A SaaS audit aims to improve a product the company already owns. It helps decide what to secure, fix, or modernize. Technical due diligence takes place before or during a transaction and makes risks understandable to a buyer or investor.
The methodology can share some checks, but the output is different. Due diligence explains the potential effect of findings on the post-close timeline, technical investment required, integration, continuity, and dependency on the existing team. It does not replace a SaaS audit outside a transaction context.
What access should be requested from the seller?
The ideal scope depends on the transaction and confidentiality constraints. Useful materials may include repositories, architecture documentation, CI/CD, Cloud inventory, monitoring, security reports, dependencies, technical costs, roadmap, incidents, and engineering organization.
We favor read-only access, dedicated accounts, time-limited permissions, and logging. We do not ask for shared passwords, root accounts, secrets sent by email, unnecessary production write access, or raw customer data exports without justification.
Can technical due diligence be performed under an NDA?
Yes. The engagement can start after an NDA is signed when the seller or buyer requires it. Information reviewed remains limited to what is necessary and access is organized around least privilege.
Accessible materials, data-room limits, and authorized people are defined before the review. Koragence does not automatically copy the whole repository or data room and does not send confidential code or customer data to an external service without an approved framework.
How does a technical due diligence engagement work?
The process is adapted to the transaction. We start with the buyer’s technical thesis, the assumptions to test, stakeholders, available access, and confidentiality limits.
Automated tools can accelerate inventory, static analysis, dependency, SBOM, secret, Cloud, or CI/CD checks. They produce signals; due-diligence findings must be verified, contextualized, and tied to a real risk.
01: frame the transaction and technical thesis, then define the assumptions that genuinely matter for the acquisition.
02: organize documents and access, favor read-only permissions, and document unavailable information.
03: review the real system across code, architecture, infrastructure, security, data, dependencies, deployments, and operations.
04: speak with the engineering team to understand choices, incidents, responsibilities, roadmap, and undocumented areas.
05: prioritize findings by evidence, impact, priority, possible action, and indicative effort, before closing or after closing.
06: present conclusions to the deal team and technical teams without making the investment decision for them.
What should a technical due diligence report contain?
The deliverable should not be a raw scanner export. It should allow each important conclusion to be traced back and understood.
Executive summary: main findings, immediate risks, and themes likely to affect takeover, readable by leadership or a deal team.
Technical map: applications, services, databases, Cloud, flows, important dependencies, and deployment elements relevant to the decision.
Risk register: finding, evidence, impact, conditions for materialization, priority, recommendation, and indicative effort when the data supports it.
Post-acquisition work: distinguish a correction taking a few days, stabilization taking several weeks, and a structural transformation taking several months.
Post-close plan: immediate, 30 days, 60 days, 90 days and beyond when relevant, without imposing a standard plan on every target.
Can technical findings affect transaction conditions?
An unexpected migration, key-person dependency, security issue, or expensive infrastructure can change the budget the buyer needs to plan after the acquisition.
Due diligence provides facts and estimates that the buyer and its financial or legal advisors may then use. Koragence does not recommend an acquisition price or draft transaction clauses.
What should happen when the data room is incomplete?
Due diligence should not hide what it could not verify. If the repository, production metrics, or certain accounts are unavailable, the report distinguishes what is verified, what is stated by the seller, and what remains unverified.
Missing data is not automatically proof of a problem. It is nevertheless a limit on the confidence the analysis can place in some statements and should remain visible in the report.
Can technical due diligence be performed quickly before a transaction deadline?
Yes, but the scope must be adapted. A short transaction timeline should not lead to a superficial review of twenty domains. It is often more useful to focus on core architecture, critical code, security, dependencies, Cloud, deployment chain, and people dependency.
Timing is defined according to scope, number of systems, available access, and the transaction deadline. We do not promise a universal 48-hour or five-day turnaround without scoping the engagement.
Buy-side or vendor due diligence: what is the difference?
Most engagements covered by this page are performed for the buyer or investor. Buy-side due diligence identifies risks and work that will be taken over after acquisition.
A company preparing for sale can also perform an upstream review to document decisions, fix obvious issues, and structure a more usable technical data room. It is the same technical need from the seller’s perspective.
What happens after the acquisition?
Due diligence can remain fully independent from the next phase. If the buyer wants to continue with Koragence, findings can feed a separate engagement for technical takeover, hardening, Cloud migration, modernization, DevOps, maintenance, or post-acquisition integration.
Remediation is never presented as automatically included. This separation protects diagnostic independence and allows the buyer to choose the right team or scope to execute the plan.
Fileen
Xwévi