Diligence flagged infrastructure as a risk
The product review went well. The team review went well. Then someone asked how production is deployed, who has access, and what happens if the cloud account is lost, and the answers went into a report with the word risk next to them. That paragraph is now part of your valuation conversation.
What reviewers write down
Technical diligence follows a pattern. Reviewers look for concentration risk, reproducibility, access control and evidence, and they write down what they cannot verify.
An investor, acquirer or their technical advisor has reviewed your infrastructure and raised findings that must be resolved or explained before the process continues.
-
“Due diligence flagged our infrastructure as a risk.”
A finding in a report does not go away when you disagree with it. It has to be resolved, mitigated or explained in writing.
-
“Only one person knows how the infrastructure works.”
Concentration risk is a standard diligence finding, and it affects deal terms because it is a retention problem as well as a technical one.
-
There is no architecture documentation that matches what is running.
Reviewers rely on what they can verify. An outdated diagram is treated as no diagram, and sometimes worse.
-
Access to production cannot be listed or evidenced.
Access control questions escalate quickly, because they bear on customer data and on every security representation in the agreement.
-
The environment cannot be reproduced from a definition.
Business continuity questions become unanswerable, and that lands in the risk section rather than the notes.
What an unresolved finding costs
Infrastructure findings rarely kill a deal outright. They change its price, its terms and its timeline.
- Deal terms
- Unresolved technical risk is negotiated as a holdback, a condition, a warranty or a lower number. All four are more expensive than fixing the finding.
- Timeline
- Each round of follow-up evidence adds weeks, and diligence rounds do not run in parallel with your roadmap.
- Post-close obligations
- Findings that survive the close become remediation commitments with dates, often supervised by someone new on your board.
- The next process
- Whatever is not fixed now is found again by the next investor, acquirer or enterprise customer, with the previous report already in their hands.
What we do about it
We start by measuring the same things a reviewer measures, then close the gaps with a platform that is documented, reproducible and demonstrably owned by you.
-
An assessment against a published standard
Your current system is measured against the eight properties of the BuiltForProd Standard, producing a prioritized list of gaps in the same language a diligence report uses.
-
Reproducibility, in code
The environment becomes an infrastructure definition in your own repositories that can be planned, reviewed and rebuilt, which answers the continuity questions directly.
-
Access and change control on the record
Single sign-on with defined roles, production changes that require review and approval, and an audit trail that cannot be turned off by an administrator.
-
The documentation set a reviewer asks for
Architecture decisions with their trade-offs, runbooks, a responsibility matrix, an escalation path and troubleshooting guides, written against the platform you actually run.
-
Ownership that is verifiable
Accounts and repositories in your company's name, no vendor named in the code, and no standing vendor access after handover. Concentration risk is answered structurally.
The outcome: Infrastructure moves from the risk section of the report to the strengths section: multi-account structure, everything in code, enforced guardrails, evidence on demand and documentation a new team could operate from.
What that is, in the portfolio
-
BuiltForProd Assessment
A fixed-fee assessment of what you run today against the eight properties of the BuiltForProd Standard, with a prioritized gap list at the end.
-
BuiltForProd Baseline
A multi-account cloud foundation in OpenTofu and Terragrunt, customized for your organization, deployed into your accounts by our engineers, then handed over with the repositories and the documentation.
-
BuiltForProd Managed
Experienced engineers who operate, secure and evolve production as an extension of your team, working through your own access, pull requests and pipelines.
What you get
-
A gap list in reviewer language
An assessment against the eight properties of the Standard, prioritized, so you can decide what to fix before the next conversation and what to explain.
-
A code-defined platform
Accounts, identity, network, logging, guardrails and delivery, deployed into accounts your company owns, with the source in your repositories.
-
The documentation pack
Architecture decision records, operational runbooks, a responsibility matrix and troubleshooting guides, all personalized to your environment.
-
Evidence you can produce on request
Configuration history, security findings, access analysis and the full change history of the platform, available without a screenshot exercise.
-
A stated ownership position
Written confirmation of what you own: the accounts, the repositories, the data and the final approval on every production change.
-
A remediation plan for what remains
An honest list of what has not been done, what it would take, and why it was sequenced that way. Reviewers trust a dated plan more than a claim of completeness.
Every repository and every cloud account stays yours. We keep no standing access after handover. See security and ownership for how that is enforced, and pricing for how an engagement is quoted.
What a reviewer can verify
Diligence rewards what can be checked, not what can be asserted.
| What | Figure | Where it comes from |
|---|---|---|
| Infrastructure defined in code | 100% | The AWS Enterprise Baseline is deployed entirely from OpenTofu and Terragrunt in your own repositories. |
| Documentation delivered | 794 pages | The documentation set behind the platform and the Blueprints shipped today, with every code sample personalized to the customer's environment. |
| Deployment sign-off | 84-item checklist | Completed and signed on every engagement, alongside 17 verification checks mapped to SOC 2 controls. |
| Audit trail | Cannot be stopped | A service control policy in the AWS Enterprise Baseline prevents anyone from stopping or deleting the audit trail or configuration recording. |
| Vendor access after handover | None | BuiltForProd holds no credential, role or standing access after handover, and nothing in the delivered code refers to us. |
| Operating model documented | 12 roles, 6 teams | The responsibility matrix delivered with the AWS Enterprise Baseline. |
The same evidence is documented page by page in the product documentation and measured against the BuiltForProd Standard.
How it works
Four steps from the first conversation to a platform your team owns.
-
Share the findings
The diligence report, the questions still open, and the timeline you are working to. If the findings are fair, we will say so.
-
Measure against the Standard
A fixed-fee assessment turns the report into a prioritized engineering plan, separating what must be fixed from what should be explained.
-
Close the gaps
The foundation is deployed into your accounts and the documentation set is produced, with verification checks and a signed deployment checklist as evidence.
-
Hand over and evidence it
Your team demonstrates the operational tasks, the ownership position is stated in writing, and the remaining plan is dated for the next review.
Yes, but…
The objections we hear on the first call, answered plainly.
The process closes in six weeks. What can realistically change?
Often the assessment and the documentation, which address the reproducibility and concentration findings directly, plus a dated plan for the rest. We will tell you what is achievable rather than promise a full rebuild.
Will a reviewer accept that we bought this rather than built it?
In our experience the opposite concern applies: bespoke infrastructure with one author is the finding. Documented, code-defined infrastructure with a support path available is a stronger position than a unique system nobody else understands.
Does using an external vendor create its own dependency risk?
Not structurally. The accounts and repositories are yours, the code names no vendor, and we hold no standing access after handover. That is exactly the question a diligence reviewer should ask, and it has a written answer.
We think the finding is wrong.
It might be. An assessment against a published standard is a useful way to say so, because it replaces a disagreement with a measured position that a third party can check.
Questions
What is technical due diligence?
Technical due diligence is the review an investor or acquirer runs over engineering before a transaction. It covers architecture, security, reliability, cost, team concentration and process, and its output is a written list of findings that feeds into price, terms and post-close obligations.
Which findings does BuiltForProd address?
The infrastructure ones: reproducibility, account and environment separation, access control, secrets handling, logging and audit trail, change management, documentation and key-person concentration. Application code quality and product architecture remain yours.
Can we start with just the assessment?
Yes, and many teams should. The assessment measures what you run against the eight properties of the Standard and produces a prioritized gap list, which is often enough to respond to the current round of questions.
What evidence can we show a reviewer?
Configuration history, security findings, access analysis, log integrity, the pull request history of every infrastructure change, the signed deployment checklist and the personalized documentation set.
Does this help with the security section of the data room?
Yes, and with the vendor questionnaires that usually follow it. The same controls and evidence answer both, which is why teams facing diligence and enterprise sales at once tend to do this work first.
More answers are in the FAQ and the support center.
Move it to the strengths column.
Send us the findings and the timeline. We will tell you which ones can be closed before the next review, which need a dated plan, and what we would deploy to make the answers verifiable.