Technical due diligence readiness: what to fix and what to disclose

Fix, disclose, or leave it?

Ask three questions. Would a reviewer treat it as a blocker? Can you fix it before the review? Is it cheaper to fix or to explain?

Fix blockers you can resolve and verify before the review. If an issue remains material and cannot be fixed in time, disclose it with a plan and an owner. Leave immaterial style issues alone, with a reason you can explain.

Fix before review Disclose with a plan Leave as is

Typical items

Fix before review: Secrets in code, ownership gaps, missing access controls

Disclose with a plan: Known debt, a planned rewrite, scaling limits

Leave as is: Style issues and anything not material to the review

Evidence to show

Fix before review: The change, the checks, and the remaining exposure

Disclose with a plan: A written disclosure, a plan, and an owner

Leave as is: The reason the issue is not material

Owner

Fix before review: The person responsible for completing and checking the fix

Disclose with a plan: The person accountable for the plan and its next decision

Leave as is: The technical lead who can explain the decision

Watch for

Fix before review: A rushed patch that hides an unresolved problem

Disclose with a plan: A disclosure with no action or accountable owner

Leave as is: Calling an issue cosmetic when it affects users or risk

The same issue can need a fix and a disclosure. Closing the immediate gap does not erase its history or remaining consequences.

Lead with AI code provenance

Be ready to explain which parts were built mostly with AI coding tools, which tools and model providers saw the code and data, how output was reviewed and tested, and whose terms cover that output.

Keep a short written record linked to the changes and reviews you can substantiate. If the history is incomplete, say what you know and what you cannot establish. Do not guess at proportions or treat a passing test as proof of ownership.

For ongoing use, agree on a review policy for agents. Name what tools may access, who reviews changes, and what evidence stays with the code.

What reviewers usually look at

The scope depends on the review. Prepare explanations and evidence for the areas that matter to the transaction or customer:

• Architecture and its limits: how the system fits together, what it depends on, and where current choices stop fitting.
• Code quality and tests: how changes are reviewed, what tests cover, and which important behavior remains unchecked.
• Security and access: who can reach code, production, and customer data, and how access is granted and removed.
• Data handling and privacy: what data you collect, where it goes, how long it stays, and who can access it.
• Code and intellectual property ownership: who created the code and what records support the company’s right to use and transfer it.
• Open source licenses: which dependencies are used and which obligations need attention.
• Infrastructure and cost drivers: what runs the system, what drives its costs, and what changes as use grows.
• The team and key-person risk: who can operate the system and explain decisions if a founder or lead leaves.
• The roadmap: what is committed, what is uncertain, and which technical constraints affect the plan.

Ownership and access: prove you control what you sell

Keep repositories, cloud services, and domain registrations in company accounts, with credentials under company control. Show who has access and who can recover each account if the current administrator leaves.

Check that contractor and agency assignments are signed and open source licenses are known. Ask qualified legal counsel to assess the terms and any gaps in the company’s rights. Access to a repository alone does not establish ownership.

See who controls code when an agency builds for the delivery boundary. UCS works in repositories and accounts your company controls. Our delivery practices explain the working arrangements.

Enterprise security and AI questionnaires

Procurement reviews are diligence too. Answer from evidence, not from intent. Name one owner to coordinate the answers, and keep an answer library current as the system and its providers change.

AI questions usually cover where data goes, whether customer data trains models, which model providers are involved, human review, and logging. Check the actual settings, data paths, terms, and operating records before answering. State a gap when the evidence does not support the requested assurance.

UCS helps enterprise customers answer AI security questionnaires.

Who answers the technical questions

Name one person who can explain past decisions and their trade-offs, find the supporting evidence, and bring in others when a question goes beyond their knowledge.

If that person is not the founder, choose around the responsibility that needs covering:

• Fractional CTO: when technology decisions need an ongoing owner whose remit includes diligence preparation. See Fractional CTO services.
• Bounded assessment: when a leader already owns the decisions and needs an outside review of a defined scope.
• Internal lead: when someone on the team has the context, authority, and time to prepare and answer.

Compare a technical consultant for a bounded question with a fractional CTO for recurring leadership. If the internal lead already covers the need, neither outside option may be necessary.

When the system came from another team

Review an inherited system before the data room opens. An agency handover, a departed founder, or an AI-built MVP can leave gaps between what runs and what the current team understands.

Establish access, operating knowledge, known risks, and who owns the next decisions. Then decide whether to refactor, rewrite, or wrap the parts that need work. A rewrite is a decision to explain, not evidence that the current system is ready.

For AI features, review what keeps an AI workflow in production, including evaluations, permissions, fallbacks, and ownership. UCS can take over operations of an AI system another team built, after a health review.

A readiness checklist

What would a reviewer treat as a blocker?

List the issues that could stop the review from progressing, with evidence for why each matters. Decide which can be fixed and checked before the review. If a blocker will remain, make it visible in the disclosure rather than letting the date decide by default.

Can we show who owns the code and accounts?

Locate the assignments, account records, access list, and dependency information that support your answer. Name any missing records and who will resolve them. Have qualified counsel review ownership and license terms that need interpretation.

Can we explain how AI tools were used and reviewed?

Write down what you can establish about the affected code, tools, providers, review, and tests. Separate recorded facts from gaps in the history. Make the record useful to the person answering the questions, without guessing at how much code was generated.

Who answers technical questions besides the founder?

Name the person and check that they can explain the architecture, risks, and reasons behind past decisions. Give them access to the relevant evidence and a way to involve specialists. A name on a document is not enough if every answer still returns to the founder.

What have we decided to disclose, and what is the plan for each item?

Keep a written list of material issues that remain, the consequence of each, the next action, and its accountable owner. Make sure the disclosure matches the system as it stands. Update it when a fix or a new finding changes the answer.

How UCS can help

• A standalone, bounded assessment, priced as a project on time and materials.
• A fractional CTO remit that includes diligence preparation, on a monthly retainer, which is preparation, not a promise of funding.
• Help answering enterprise AI security questionnaires.

UCS can fix the blockers the assessment finds as a separate project, so you can stop after the assessment.

UCS can help you document how AI coding tools were used and reviewed in your codebase.

Bring the review date and what is in scope

Bring the review type, whether investor, acquirer, or enterprise, the date, what has been requested, and who owns technology today. Do not send confidential documents.

You can also email hello@ucs.tech with the review type and what is in scope.

Questions before we start

What is technical due diligence?

Technical due diligence is a review of a company’s technology that an investor, acquirer, or enterprise customer runs before committing. It usually covers architecture, code quality, security, data handling, code and IP ownership, infrastructure, and the team that runs it.

Should we fix issues or disclose them before due diligence?

Fix what a reviewer would treat as a blocker and you can fix in time, such as exposed secrets, unclear code ownership, or missing access controls. Disclose the rest in writing with a plan and an owner. A known issue with a plan is easier to accept than one the reviewer finds.

How do we answer questions about AI-generated code in due diligence?

Keep a short written record of which parts were built mostly with AI coding tools, which tools and model providers saw your code and data, and how the output was reviewed and tested. Answer from that record rather than from memory, and avoid guessing at proportions.

Who should answer the technical questions in due diligence?

One person who can explain past decisions and their trade-offs. If the founder cannot, a fractional CTO whose remit includes diligence preparation, or an outside reviewer for a bounded assessment, can fill the gap. At UCS, that is preparation, not a promise of funding.

Can UCS help us answer an enterprise AI security questionnaire?

Yes. UCS helps enterprise customers answer AI security questionnaires. Expect questions about where data goes, whether customer data trains models, which model providers you use, and how outputs are reviewed and logged. Answer from evidence, and name one owner for the answers.

Do we need a fractional CTO for due diligence or a one-off assessment?

If a leader can already answer technical questions and wants an independent view, a standalone, bounded assessment fits. If nobody owns technology decisions, that is a leadership gap, and a fractional CTO remit can cover the preparation and the decisions that follow.