Planning an acquisition but can’t verify the technology risks before signing an LOI?
ISHIR delivers independent technical due diligence assessments with documented findings, risk analysis, and a prioritized verification and remediation roadmap.
You’re about to acquire a software company. The financials look promising. Customer retention is strong. The product works. But there’s one problem: the seller won’t give you access to the source code until you sign a Letter of Intent (LOI).
Your investment team wants answers. Your CTO wants to inspect the architecture. Your legal team wants to protect the transaction timeline. Meanwhile, the seller insists that providing source code before exclusivity creates unnecessary intellectual property and confidentiality risks.
So what do you do?
Sign the LOI and hope the technology holds up? Delay the deal until the seller opens the codebase? Or find a way to evaluate the technical risks without accessing the source code?
There is a better approach.
Technical due diligence before an LOI does not always require full source code access. Buyers can evaluate meaningful technology risks using architecture documentation, cloud billing records, security assessments, software dependency inventories, engineering interviews, and controlled product demonstrations.
The distinction is important. You can identify risks and challenge technical assumptions before the LOI. You cannot conclusively validate code quality, security, intellectual property ownership, or production scalability without sufficient supporting evidence.
The goal is not to pretend you have completed a full technical audit.
It is to understand what you are buying, which risks could affect the deal, and what must be verified before closing.
Technical due diligence before an LOI is a preliminary, evidence-based assessment of a company’s technology, designed to identify material risks before a buyer commits to proposed deal terms.
An LOI, or Letter of Intent, typically outlines preliminary acquisition terms, including valuation, transaction structure, diligence arrangements, and potentially an exclusivity period. Although many commercial terms are nonbinding, certain provisions, such as confidentiality and exclusivity, may be binding depending on the agreement.
Before an LOI, buyers often have limited access to confidential technical information. Sellers may share financial and commercial documentation but restrict source code repositories, infrastructure credentials, detailed security reports, and access to engineering personnel.
That does not make technical evaluation impossible.
A properly scoped pre-LOI technical due diligence assessment focuses on three questions:
1. Does the available technical evidence support the business and valuation assumptions?
2. Are there warning signs that could create significant post-acquisition costs, delays, or operational risks?
3. Which critical claims remain unverified and require deeper post-LOI investigation?
Consider a business acquiring a SaaS platform for its recurring revenue and future growth potential.
The seller claims the application can support ten times its current customer base without major architectural changes.
That claim influences valuation.
But what evidence supports it?
Has the application undergone load testing? Are there known database bottlenecks? Do cloud costs increase predictably with usage? Is the system dependent on one engineer who understands the infrastructure?
These questions can be investigated before reviewing every line of code.
The buyer may not be able to confirm scalability conclusively, but they can determine whether the seller’s claims are credible, questionable, or unsupported.
That is the purpose of pre-LOI technical due diligence.
A seller’s refusal to share source code is not automatically a red flag.
Source code represents valuable intellectual property. Granting unrestricted access to potential buyers creates legitimate concerns about confidentiality, competitive exposure, proprietary algorithms, trade secrets, and misuse of technical information.
This is particularly sensitive when the buyer operates in the same industry.
A seller may also be speaking with multiple potential acquirers. Providing repository access to every interested party would create unnecessary security and commercial risks.
Instead, sellers frequently use staged disclosure.
Before the LOI: Buyers may receive architecture summaries, financial and operating metrics, selected security records, and management presentations.
After the LOI: The seller may permit deeper technical diligence through controlled repositories, infrastructure reviews, engineering interviews, and additional data-room access.
Before closing: Buyers seek to complete confirmatory diligence, resolve material findings, and determine whether the agreed transaction terms remain appropriate.
The exact sequence depends on the transaction and negotiated access rights.
The problem is not that the seller restricts source code.
The problem arises when a buyer cannot obtain enough credible evidence to evaluate the risks that matter to the investment decision.
A buyer who confuses confidentiality restrictions with technical concealment may unnecessarily damage a good transaction.
A buyer who accepts unsupported technical claims may inherit problems that could have been identified earlier.
Both mistakes are avoidable.
Source code is only one source of technical evidence.
A company’s technology also leaves a trail through architecture documentation, infrastructure expenses, security assessments, software dependencies, engineering practices, and production behavior.
Here are seven areas buyers should investigate.
What to request: System architecture diagrams, infrastructure topology, database architecture, API documentation, technology stack inventory, and deployment architecture.
Architecture documentation provides an initial view of how the application is structured and how its components interact.
It helps answer questions such as:
For example, suppose a buyer plans to acquire a logistics technology platform and integrate it with several enterprise resource planning systems.
The seller claims integration will be straightforward.
But its architecture documentation shows that most integrations depend on custom database procedures, direct database connections, and manual synchronization.
That finding does not prove the platform is poorly engineered.
However, it challenges the assumption that integration will be simple, inexpensive, and fast.
The buyer now has a specific issue to investigate before agreeing to a valuation based on rapid post-acquisition integration.
What remains unverified: Whether the deployed software accurately matches the diagrams, whether implementation quality is acceptable, and whether the documented architecture performs as claimed.
Architecture diagrams show design intent. They are not proof of implementation quality.
What to request: Six to twelve months of cloud invoices, resource usage summaries, major service cost breakdowns, reserved capacity commitments, and infrastructure forecasts.
Cloud billing records can reveal how a technology platform consumes resources and how those costs change over time.
This is particularly relevant when the seller claims the product can scale profitably.
Suppose a SaaS company’s cloud spending increases from $30,000 to $55,000 per month while its customer base grows only 10%.
That difference deserves investigation.
The additional spending could reflect infrastructure inefficiencies, poorly optimized database queries, excessive logging, overprovisioned compute resources, increased AI inference costs, or a legitimate investment in capacity ahead of growth.
The invoices alone cannot determine which explanation is correct.
But they tell the buyer where to investigate.
A useful pre-LOI assessment compares infrastructure expenses against business activity, such as active users, transactions, API requests, customer workloads, or AI inference volume.
It should also identify contracts and commitments that may survive the acquisition.
What remains unverified: Whether the underlying application is efficiently coded, whether performance will remain stable at higher traffic levels, and the precise remediation cost without deeper infrastructure evidence.
What to request: SOC 2 reports, ISO 27001 certification and scope where applicable, penetration testing summaries, vulnerability remediation records, security policies, incident logs, disaster recovery plans, and security insurance details.
Security exposure is not just an engineering concern. It can become an acquisition cost, regulatory issue, customer retention problem, or operational disruption.
According to IBM’s 2026 Cost of a Data Breach Report, the global average cost of a data breach reached $4.99 million, a 12% increase from the previous report.
That figure is an average across organizations studied, not an estimate of any specific acquisition target’s expected loss. Nevertheless, it illustrates why cybersecurity risk deserves attention during investment decisions.
Security records can help buyers understand whether the target has established procedures for protecting sensitive information and managing vulnerabilities.
A SOC 2 Type II report, for example, can provide evidence about specified controls and their operation during a defined review period. It does not guarantee that the entire application is free from vulnerabilities.
Similarly, a penetration test completed two years ago may provide little assurance about a system that has undergone significant architectural changes since then.
The buyer should examine report dates, tested systems, exclusions, findings, and remediation evidence.
A particularly important question is whether management can demonstrate that previously identified critical vulnerabilities have been resolved.
What remains unverified: Undiscovered vulnerabilities, current exploitable code-level weaknesses, undisclosed incidents, and security issues outside the scope of available assessments.
No source code access means there are limits to independent security validation. Even a code review would not establish that the system is completely secure.
What to request: A Software Bill of Materials (SBOM), third-party dependency inventory, open-source licensing records, commercial software agreements, and available software composition analysis reports.
Modern software applications rarely consist entirely of proprietary code.
They rely on open-source libraries, external services, commercial frameworks, and third-party components.
These dependencies can introduce security, maintenance, licensing, and continuity risks.
The U.S. Cybersecurity and Infrastructure Security Agency, CISA, released updated 2026 Minimum Elements for a Software Bill of Materials, strengthening guidance around component identification, license information, and software supply-chain transparency.
For buyers, dependency records may identify:
For example, a business may depend on a commercial technology component licensed to the seller under terms that do not automatically permit assignment following a change of control.
The buyer needs to understand whether that dependency could affect the transaction or post-closing operations.
However, an SBOM is only as reliable and complete as the process used to generate it.
A seller-provided inventory cannot independently prove that all dependencies have been identified.
What remains unverified: Complete dependency coverage, actual license compliance, embedded proprietary code, and the full legal chain of ownership.
Software licensing and IP ownership conclusions should be reviewed with qualified legal counsel.
What to request: A structured interview with the CTO, head of engineering, or another authorized technical leader, along with an engineering organization chart and selected process documentation.
A polished product demonstration tells you what the application does.
A serious engineering conversation reveals how the organization keeps it operating.
Ask practical questions.
What was the last major production incident?
How was it detected?
How long did recovery take?
Who approves production deployments?
Which parts of the application are most difficult to change?
What would the engineering team redesign if it had six months without new feature commitments?
How many people can independently deploy and recover the production environment?
These questions help expose risks that are rarely visible in a financial presentation.
For instance, a business might employ fifteen developers, but only one senior engineer understands the database architecture, production deployment procedures, and critical external integrations.
If that engineer leaves after the acquisition, knowledge concentration could become a major operational issue.
The question is not whether the company has enough developers.
It is whether the business can maintain and evolve its technology without depending on a few individuals.
What remains unverified: Whether management’s statements accurately represent day-to-day engineering practices and whether the team’s capabilities match the claims.
Those claims should later be checked against repository history, runbooks, incident records, and direct engineering evidence.
What to request: A live, technically guided demonstration conducted by an authorized engineering representative, preferably using test data and a controlled environment.
A sales demonstration is designed to show the product at its best.
Technical due diligence needs to investigate how the system behaves when conditions are less favorable.
Instead of asking the seller to repeat a standard product walkthrough, ask them to demonstrate specific workflows.
For a financial software platform, that might include handling duplicate transactions, payment failures, and reconciliation exceptions.
For a healthcare application, it could involve system permissions, audit trails, and failed integration requests.
For a SaaS platform, it may include administrative access controls, recovery procedures, or the behavior of critical workflows when a dependency becomes unavailable.
The objective is not to break the seller’s application.
It is to test whether the product’s observable behavior supports the seller’s claims.
All demonstrations should be mutually agreed upon and conducted within authorized environments. Buyers should not perform unapproved penetration tests or attempt to access restricted systems.
What remains unverified: Source-level implementation, underlying architecture quality, full production performance, and whether the demonstrated environment accurately represents production.
A successful demonstration is evidence of a demonstrated behavior, not proof that the entire system is production-ready.
What to request: AI system architecture, model provider inventory, data-flow diagrams, model evaluation summaries, AI operating costs, data retention policies, and relevant vendor contracts.
This area matters when the acquisition target relies on generative AI, machine learning, or AI agents for a material part of its product.
A company may market its platform as proprietary AI while relying heavily on third-party foundation models, hosted APIs, and externally managed data services.
There is nothing inherently wrong with that architecture.
The risk arises when the buyer does not understand what the company owns, controls, or depends on.
Important questions include:
Who controls the model or models?
What happens if the model provider changes its pricing or service terms?
Can the application switch providers?
Does the company have contractual rights to use its training and operational data?
How are model outputs evaluated?
What safeguards exist for sensitive information?
Does the product have a fallback strategy when AI services fail?
A product can deliver meaningful business value using third-party models. Due diligence should assess that value and the associated dependencies rather than assume third-party model usage makes the company less legitimate.
What remains unverified: Independent model performance, completeness of evaluation coverage, hidden data dependencies, and actual behavior across untested operating conditions.
For AI-heavy acquisitions, these unknowns may justify a dedicated post-LOI AI due diligence workstream.
This is where many preliminary technical assessments become misleading.
A reviewer examines a few diagrams, reads the seller’s security policy, attends a demonstration, and produces a report that sounds like a completed technical audit.
That is not credible due diligence.
A trustworthy assessment separates verified evidence, preliminary indications, and unresolved questions.
The right question is not, “Have we reviewed enough documents?”
It is, “Do we have sufficient evidence to make this particular decision, and which assumptions still require confirmation?”
That distinction protects both the buyer and the credibility of the assessment.
A preliminary assessment should be short, decision-focused, and proportionate to the size and complexity of the deal.
The following five-step process can be adapted to the transaction and the level of seller cooperation.
Begin with the investment thesis.
Why is the buyer acquiring this business?
Is the value based on recurring revenue, proprietary technology, accelerated market entry, integration potential, customer data, or future scalability?
Now identify the technical assumptions supporting that value.
For example, if the acquisition strategy depends on integrating the seller’s platform into an existing enterprise ecosystem within six months, integration complexity is a priority.
If the buyer plans to expand a SaaS platform aggressively, scalability and infrastructure economics matter more.
If the target’s value depends on AI capabilities, model dependencies, data rights, and evaluation evidence become central.
Do not spend the entire preliminary assessment reviewing low-impact documentation while leaving the investment thesis untested.
A preliminary technical data room does not need to contain everything.
It needs enough information to test the most material assumptions.
A focused request can cover architecture documentation, infrastructure cost summaries, security reports, dependency inventories, key vendor contracts, engineering structure, and product demonstrations.
Where information is sensitive, agree on redactions, controlled viewing, or an independent review arrangement.
Each request should have a clear purpose.
If a document will not materially improve the buyer’s decision, it may not belong in the initial review.
A statement is not evidence simply because the CTO made it.
If management says the platform is highly scalable, compare that claim with infrastructure spending, available performance results, architectural design, and operational history.
If management says the platform has strong security, compare its policies with assessment dates, unresolved findings, and remediation records.
If management says its AI capabilities are proprietary, examine model contracts, data rights, system dependencies, and the technical explanation of its differentiation.
Look for consistency across multiple sources.
Where the evidence conflicts, document the discrepancy and request clarification.
Where evidence is unavailable, record the limitation.
Not every technical weakness should threaten a transaction.
An outdated internal reporting interface is not equivalent to an unresolved critical security exposure.
Findings should be evaluated based on business impact, likelihood, available evidence, and the effort required to investigate or remediate them.
A useful classification is:
Critical: A potentially material issue that could affect the decision to proceed and requires urgent validation.
High: A significant risk that could affect valuation, integration strategy, or post-acquisition costs.
Moderate: A meaningful limitation that can potentially be addressed through a planned remediation program.
Low: A manageable issue unlikely to affect the investment decision materially.
Unverified: A material claim or risk for which sufficient evidence has not yet been obtained.
Confidence must be reported separately from severity.
For example, a suspected licensing problem could have high potential impact but low confidence until contracts and implementation details are examined.
This prevents a preliminary hypothesis from being misrepresented as a confirmed defect.
The final deliverable should help the buyer decide what to do next.
It should explain which assumptions are supported, which findings create concern, what evidence is missing, and what additional work must occur after the LOI.
It should also translate technical findings into business consequences.
A critical dependency risk may affect post-close operating continuity.
An architectural limitation may affect the buyer’s growth strategy.
A security gap may create remediation costs or contractual exposure.
An undocumented integration may extend the planned transition timeline.
The report should not simply say that the technology has problems. It should explain what those problems mean for the acquisition.
Where evidence permits, it should provide preliminary remediation effort ranges, assumptions, and confidence levels.
Where evidence does not permit credible cost estimates, it should explicitly say that further investigation is required.
An executive should not need to read fifty pages of engineering observations to understand whether the transaction deserves further investment.
The report should be designed around decisions.
A practical pre-LOI technical due diligence report can include an executive summary, investment-thesis risk assessment, evidence register, material findings, business impact analysis, confidence ratings, unresolved questions, and a prioritized post-LOI verification plan.
Consider the following hypothetical example:
These are illustrative findings, not conclusions about an actual acquisition target.
The purpose is to connect every issue with a decision and a next action.
A serious report should also include a section titled “What We Could Not Verify.”
That section is not a weakness in the assessment.
It is evidence that the reviewer understands the boundaries of the work performed.
A preliminary technical assessment should inform the LOI negotiation, not replace post-LOI diligence.
Before signing, buyers should discuss the following with their transaction counsel.
Defined technical access: Specify what technical records, authorized personnel, repository access, and infrastructure information will be made available during confirmatory diligence.
A realistic diligence period: Allow sufficient time for the complexity of the technology and the required technical tests.
Confidentiality and access controls: Establish how sensitive code, customer data, security records, and proprietary information will be protected.
Independent reviewer access: Where appropriate, allow an agreed third-party assessor to review sensitive materials and provide restricted findings without disclosing proprietary code to the broader buyer team.
Handling material findings: Ensure the proposed transaction structure and definitive agreements can appropriately address issues discovered during diligence.
Outstanding evidence requirements: Record which material claims require confirmation before the buyer proceeds to closing.
These are matters for legal negotiation, not engineering decisions alone.
In some transactions, a controlled review or clean-team arrangement may be appropriate. Such arrangements require careful legal structuring, especially when competitors or competitively sensitive information are involved.
A seller may be justified in protecting its source code.
A buyer is equally justified in refusing to treat unverified technology claims as established facts.
Both interests can be addressed through a properly structured diligence process.
A seller refusing unrestricted source code access before an LOI is not, by itself, a reason to abandon an acquisition.
The more important warning sign is an inability or unwillingness to support material technical claims through any reasonable, secure review mechanism.
Consider three situations.
Situation 1: The seller restricts source code but provides credible alternative evidence.
The company shares architecture documentation, security assessments, dependency records, infrastructure summaries, and access to technical leadership.
The remaining gaps are clearly identified and scheduled for post-LOI verification.
This may represent a reasonable staged diligence process.
Situation 2: The seller provides documents, but major claims are inconsistent.
Cloud expenses do not align with usage growth. Security documentation is outdated. Architecture records conflict with technical explanations.
These discrepancies require investigation before relying on the seller’s projections.
They do not automatically establish wrongdoing or technical failure.
Situation 3: The seller makes material claims but refuses meaningful verification.
The transaction valuation depends on proprietary AI, scalability, or software ownership, yet the seller refuses reasonable supporting evidence and provides no workable path for independent post-LOI validation.
That creates a different level of uncertainty.
The buyer may need to reconsider the proposed valuation, require stronger diligence provisions, restructure the transaction, or decline to proceed.
The decision should be driven by the materiality of the unresolved risk, not by the mere absence of source code access.
Acquisition decisions should not depend entirely on a seller’s technical presentation.
But buyers also should not be forced to choose between signing an LOI without technical insight and abandoning a promising opportunity because repository access is restricted.
ISHIR helps investors, private equity firms, corporate development teams, and business owners evaluate technology risks before committing capital.
Through its Technical Due Diligence Assessment Services, ISHIR provides independent technical evaluation across software architecture, security, scalability, codebase quality, engineering processes, technical debt, third-party dependencies, and AI readiness.
For pre-LOI transactions, the review can be scoped to the evidence available.
Depending on what the seller authorizes, this may include architecture analysis, cloud cost evaluation, existing security records, licensing and dependency reviews, engineering discussions, and controlled technical demonstrations.
The assessment is designed to distinguish supported findings from assumptions and unresolved questions.
Rather than presenting a limited-access review as a complete code audit, ISHIR can document the assessment boundaries and identify which areas require confirmatory testing after the LOI.
A company’s source code matters.
But it is not the only evidence of technical risk.
Infrastructure costs, architectural decisions, security records, software dependencies, engineering operations, and demonstrated system behavior can reveal important information about the technology behind a business.
The mistake is assuming that limited access makes meaningful technical due diligence impossible.
The opposite mistake is treating preliminary evidence as proof that the technology has been fully validated.
Both can lead to expensive decisions.
Technical due diligence before an LOI should answer a practical question: Do we know enough about the technology to justify moving forward, and do we have a credible plan to verify what we still don’t know?
For a buyer preparing to invest millions in an acquisition, that is a question worth answering before the deal moves further.
ISHIR delivers independent technical due diligence assessments with documented findings, risk analysis, and a prioritized verification and remediation roadmap.
Yes. Preliminary technical due diligence can evaluate architecture documents, cloud expenses, security assessment records, software dependencies, engineering practices, and product behavior without full source code access. However, code quality, certain security risks, and implementation-level claims cannot be independently confirmed through documentation alone. The report should clearly distinguish verified evidence from unresolved risks.
Both stages serve different purposes. Pre-LOI technical due diligence identifies material warning signs and helps buyers evaluate proposed deal terms. Post-LOI due diligence provides deeper verification through agreed access to source code, infrastructure, security evidence, and engineering systems. The appropriate depth depends on transaction size, technical complexity, and seller cooperation.
Buyers should prioritize system architecture diagrams, technology stack inventories, cloud billing records, security assessment summaries, software dependency and licensing inventories, engineering organization information, and relevant operational documentation. The request should be proportionate to the investment thesis and the information the seller can disclose safely.
A buyer can identify indicators of engineering maturity through documentation, incident history, release processes, testing records, and technical interviews. However, these indicators do not replace direct code analysis. A definitive evaluation of implementation quality generally requires appropriate access to the source code and supporting engineering evidence.
Not necessarily. Sellers have legitimate reasons to protect intellectual property and confidential technical information. The concern increases when the seller refuses reasonable alternative evidence or will not commit to a workable post-LOI verification process. Buyers should evaluate the level of cooperation and material unresolved risks rather than treating restricted code access as proof of a problem.
The timeline depends on transaction complexity, documentation quality, available technical access, and the scope of review. A narrowly defined red-flag assessment can be faster than a comprehensive audit. Buyers should agree on the scope, evidence requirements, review milestones, and reporting deadline before beginning the engagement.
Pre-LOI technical due diligence is a transaction-focused risk assessment intended to inform an investment or acquisition decision. A code audit examines the implementation itself, including code quality, maintainability, dependencies, and potential security issues. A code audit may form part of post-LOI technical due diligence when the buyer receives appropriate repository access.
Yes. Preliminary findings can reveal risks affecting operating expenses, integration costs, required investment, growth assumptions, or business continuity. These findings may influence the buyer’s proposed valuation or transaction structure. However, preliminary estimates must be presented with their assumptions and confidence levels, and material findings should be confirmed during deeper diligence.
A mutually approved independent reviewer may be able to inspect source code under appropriate confidentiality and access restrictions and provide a limited findings report. The arrangement should define scope, permissions, reporting boundaries, and how sensitive information is protected. Buyers should involve transaction counsel when negotiating such arrangements.
The buyer should review the material findings, determine whether to proceed, and incorporate outstanding technical verification requirements into the next transaction stage. Post-LOI diligence should prioritize unverified claims, high-impact risks, repository analysis, security testing where authorized, infrastructure validation, and remediation estimates. The final objective is an informed acquisition decision supported by technical evidence.
The post The Seller Won’t Share Source Code? How to Perform Technical Due Diligence Before an LOI appeared first on ISHIR | Custom AI Software Development Dallas Fort-Worth Texas.
