I’m going to give you ten questions. They’re the questions that, if asked during technical due diligence, would have changed the outcome of deals I’ve been brought in to assess post-close. They’re the questions whose answers distinguish between a technology asset worth the price and a technology liability dressed in a good management presentation.
These aren’t theoretical. Every question on this list exists because I’ve seen a specific deal where the answer would have changed the structure, the price, or the decision. I’ve framed them so that a non-technical investor can ask them and evaluate the answers, because the best DD questions are the ones that force clarity even when the person asking doesn’t have an engineering background.
Question 1: When did an independent technical assessor last examine the production system?
Not when did the CTO last present architecture slides. When did someone with no stake in the outcome look at the actual running system, talk to the engineers and form an independent view?
If the answer is “never,” you’re looking at a technology that nobody outside the company has evaluated. That’s not automatically disqualifying, plenty of good companies haven’t had independent tech assessments. But it means that every claim about the technology’s quality is unverified.
If the answer is “during our last fundraise,” ask what they found and what was remediated. If the answer is “we just completed one as part of preparing for this process,” ask to see the report and note that a sell-side commissioned assessment has inherent bias worth adjusting for.
Question 2: How many people can deploy code to production and what happens if they all leave?
This question reveals the deployment maturity and key-person risk in a single answer.
In a mature engineering organisation, any engineer can deploy through an automated CI/CD pipeline. The deployment process is documented, repeatable and independent of any individual. In a distressed or under-resourced organisation, deployment often depends on one or two people running manual processes that only they understand.
If fewer than three people can deploy to production, that’s a key-person risk that belongs in the investment memo. If the deployment process is manual and undocumented, the cost of building proper deployment infrastructure belongs in the integration budget.
Question 3: What’s the test coverage on the three most business-critical modules?
Not the overall test coverage number. The coverage on the specific code that handles money, customer data, authentication and core business logic.
The best technical due diligence companies always break coverage down by module because the aggregate number is nearly always misleading. 75% overall coverage means nothing if the payment processing module is at 10%.
If the answer is “we don’t know the per-module breakdown,” that’s itself a finding, it means the engineering team doesn’t track where their test investment is distributed, which usually means it’s not distributed well.
Question 4: Show me the load test results at 3x current volume.
Not “can the system handle 3x volume?” Show me the test that proves it.
If load tests exist and show clean results at the growth targets in your financial model, that’s a validated growth thesis. If load tests exist and show degradation, you’ve identified an infrastructure investment that needs to be in the model. If load tests don’t exist, the growth thesis is untested, which means the price is based on an assumption that nobody has verified.
Question 5: What’s the SOC 2 (or equivalent) certification scope and does it cover the production platform?
Security certifications are meaningful only to the extent that they cover the systems that matter. A SOC 2 Type II certification that covers corporate IT but not the production SaaS platform is a certification that doesn’t protect you.
Ask to see the audit scope documentation. If the production environment isn’t in scope, the certification doesn’t tell you what you need to know about the security of the product you’re buying.
Read also: Mastering Index Technical Analysis for Consistent Profits in India
Question 6: Who owns the intellectual property, the company entity or individuals?
Pull the actual IP registrations and cross-reference against the corporate entity. Then check contractor agreements from the company’s first two years for IP assignment clauses.
This question has delayed and restructured more deals than any technical finding in my experience. It takes a day to verify and can save months of post-close negotiation.
Question 7: What’s the cloud cost per unit of business activity and what does it project to at your growth targets?
Not total cloud spend, cost per transaction, per active user, or per API call. This is the metric that connects infrastructure cost to business performance.
If the cost per unit increases as volume grows, the margin assumptions in the financial model may be wrong. The architecture may produce great margins at current scale and progressively worse margins as it grows, which directly undermines the growth thesis that justifies the acquisition price.
Question 8: What are the top three vendor dependencies and what happens if any of them changes terms?
Map the critical third-party dependencies and assess the switching cost for each. Check for change-of-control provisions in vendor contracts that could trigger renegotiation at the moment of acquisition.
A product deeply coupled to a single vendor’s proprietary SDK with no abstraction layer inherits that vendor’s pricing power. If the vendor doubles their rates knowing you’re locked in, your unit economics change and you have no short-term recourse.
Question 9: What do the engineers know that the pitch deck doesn’t say?
This isn’t a question you ask the CTO in a management presentation. This is a question your technical assessor answers by talking to the engineering team directly, reviewing internal documentation and reading between the lines of the codebase.
The engineers know the system’s failure modes, its technical debt, its scalability ceiling and the decisions made under pressure that created risk. This knowledge exists in every technology company. The DD process is the mechanism for accessing it before close rather than discovering it after.
Question 10: What’s the realistic engineering cost to execute the first 12 months of the product roadmap?
Take the roadmap’s top three commitments and have the technical assessor estimate the engineering effort assuming the current architecture and team composition. Compare that estimate to what’s in the financial model.
The gap between these two numbers is the conversation to have before signing. Features that require fundamental architectural changes, not incremental development, appear on roadmaps regularly without the corresponding engineering cost appearing in the budget.
Using these questions
These ten questions don’t replace a comprehensive technical due diligence assessment. They’re the questions that determine whether the comprehensive assessment is worth commissioning and the ones whose answers most frequently change deal outcomes.
The questions work best when asked early in the deal process, at the same stage as financial DD, not as a late-stage validation after the price is informally set. Technical findings that surface early inform valuation and structure. Technical findings that surface late create friction and renegotiation.
The investment firms that consistently do this well share a practice: they treat the technical assessment as a pricing tool, not a risk filter. The findings don’t kill deals, they inform deal structure, price and integration planning. The acquirer who understands the technology’s strengths and weaknesses is in a better negotiating position and a better integration-planning position than one who discovers the reality post-close.
