[{"data":1,"prerenderedAt":416},["ShallowReactive",2],{"archive-2025":3,"categories":377},[4],{"date":5,"authorId":6,"category":7,"tags":8,"image":14,"readingTime":15,"published":16,"cluster":17,"post_type":18,"faq":19,"id":32,"title":33,"body":34,"description":370,"extension":371,"meta":372,"navigation":16,"path":373,"seo":374,"stem":375,"__hash__":376},"2025-01-20",2,"due-diligence",[9,10,11,12,13],"technical due diligence checklist","tech stack assessment","software architecture review","due diligence","investors","https:\u002F\u002Fimages.unsplash.com\u002Fphoto-1551288049-bebda4e38f71?w=1200&q=80",11,true,"C — Technical Due Diligence","spoke",[20,23,26,29],{"question":21,"answer":22},"What is the difference between a technical due diligence checklist and a full technical assessment?","A checklist is the framework for what to examine. A full technical assessment is the work of actually examining it — reading the code, interviewing the team, reviewing the infrastructure, and producing a written report with risk ratings and recommendations. The checklist tells you what questions to ask. The assessment answers them.",{"question":24,"answer":25},"How long does a technical due diligence take?","A properly scoped technical assessment takes three to seven business days. Longer engagements are not necessarily more thorough — they are often less focused.",{"question":27,"answer":28},"Can a non-technical person run a technical due diligence?","A non-technical person can conduct the business and process portions of an assessment. The technical domains — architecture, code quality, security, IP — require someone who can read code, review infrastructure, and ask questions that a well-prepared team cannot deflect with jargon.",{"question":30,"answer":31},"What does technical due diligence cost?","Costs vary by scope, timeline, and the complexity of the system being assessed. A three-to-seven-day engagement with a senior technical team typically runs significantly less than the cost of discovering a material technical risk six months after a deal closes.","content\u002Fblog\u002Ftechnical-due-diligence-checklist.md","The Technical Due Diligence Checklist: What a Senior Assessment Actually Covers",{"type":35,"value":36,"toc":357},"minimark",[37,41,44,47,52,55,58,61,65,72,75,94,100,104,109,111,137,142,146,151,153,173,178,182,187,189,209,214,218,223,225,239,244,248,253,255,269,274,278,283,285,302,307,311,316,318,332,337,341,344,347],[38,39,40],"p",{},"A checklist only works if it asks the right questions.",[38,42,43],{},"Most technical due diligence checklists available online were written by people who have never actually opened a codebase under acquisition pressure — they cover the obvious surface areas (does the company use version control? is there documentation?) and miss the things that actually determine whether the technology can support the business thesis.",[38,45,46],{},"This is the checklist we use. It covers eight domains: software architecture and scalability headroom, code quality and maintainability, infrastructure and operational maturity, security posture and compliance exposure, intellectual property and licensing risk, third-party dependencies and vendor lock-in, team structure and knowledge concentration, and technical debt — quantified, not estimated.",[48,49,51],"h2",{"id":50},"what-makes-a-technical-due-diligence-checklist-actually-useful","What makes a technical due diligence checklist actually useful",[38,53,54],{},"A useful checklist does one thing a generic one does not: it separates the questions that reveal the condition of the technology from the questions that reveal the condition of the team that built it.",[38,56,57],{},"Both matter. But they tell different stories, and they require different assessment methods. You can have a technically sound codebase built by a team that has already left. You can have a fragile codebase built by a team that fully understands it and has a credible plan to address it. The risk profile of those two situations is completely different — and a checklist that only looks at the code misses half the picture.",[38,59,60],{},"The eight domains below are structured to surface both.",[48,62,64],{"id":63},"domain-1-software-architecture-and-scalability-headroom","Domain 1: Software architecture and scalability headroom",[38,66,67,71],{},[68,69,70],"strong",{},"The core question:"," Can the architecture support the business thesis — not just current load, but the load that justifies the investment?",[38,73,74],{},"What to assess:",[76,77,78,82,85,88,91],"ul",{},[79,80,81],"li",{},"Is the architecture monolithic, service-oriented, or microservices? There is no universally correct answer — the right architecture depends on team size, scale requirements, and operational maturity. The wrong answer is one that does not match any of those.",[79,83,84],{},"Is the system stateless where it needs to be to scale horizontally?",[79,86,87],{},"Where are the bottlenecks? Every system has them. A team that cannot tell you where theirs are has not looked — or has looked and is not telling you.",[79,89,90],{},"What is the database architecture? Read\u002Fwrite split? Sharding strategy? Connection pooling? For systems that need to scale, the database is almost always the first constraint.",[79,92,93],{},"What does the architectural decision log look like? Recorded decisions indicate a team that reasons about architecture deliberately. No record indicates a team that makes architectural decisions by default.",[38,95,96,99],{},[68,97,98],{},"What a red flag looks like:"," A system described as \"microservices\" that has a single shared database. This is not a microservices architecture — it is a distributed monolith with the operational overhead of microservices and none of the scalability benefits.",[48,101,103],{"id":102},"domain-2-code-quality-and-maintainability","Domain 2: Code quality and maintainability",[38,105,106,108],{},[68,107,70],{}," Can a new team member get productive in this codebase in a reasonable amount of time?",[38,110,74],{},[76,112,113,116,119,122,125],{},[79,114,115],{},"Test coverage — and more importantly, the quality of what is being tested. A 90% coverage number means nothing if the tests only verify that functions run without throwing errors.",[79,117,118],{},"Code consistency: does the codebase follow a documented style guide, enforced by tooling? Inconsistency signals either a lack of process or a team that has grown faster than its practices.",[79,120,121],{},"Cyclomatic complexity on critical paths. Complex code is not bad by definition — but complex code with no tests and no documentation is a liability.",[79,123,124],{},"PR review history. Look at the comments. Do they catch real issues? Or are they approvals with no friction? A team that rubber-stamps pull requests is a team whose quality gate does not exist.",[79,126,127,128,132,133,136],{},"Documentation at the right level of abstraction. Code-level comments explaining ",[129,130,131],"em",{},"what"," the code does are usually noise. Architecture-level documentation explaining ",[129,134,135],{},"why"," decisions were made is rare and valuable.",[38,138,139,141],{},[68,140,98],{}," A codebase with near-zero commit history on anything outside of feature branches. Either no one is reviewing code, or the team has been working outside of version control and importing final code. Neither is recoverable without a full reset of engineering practices.",[48,143,145],{"id":144},"domain-3-infrastructure-and-operational-maturity","Domain 3: Infrastructure and operational maturity",[38,147,148,150],{},[68,149,70],{}," Can this system be operated reliably at the scale the business requires, and can it recover when it fails?",[38,152,74],{},[76,154,155,158,161,164,167,170],{},[79,156,157],{},"Deployment pipeline: is there one? Is it automated? Can a change be deployed in minutes or days?",[79,159,160],{},"Environment parity: are development, staging, and production environments consistent? Environments that drift from each other produce bugs that only appear in production — the most expensive kind.",[79,162,163],{},"Monitoring and alerting: what is being monitored, at what thresholds, and who is alerted? A system with no monitoring is a system where failures go undetected until users complain.",[79,165,166],{},"Incident history and post-mortems: how the team responds to failure is more informative than whether they have failed.",[79,168,169],{},"Cloud cost structure: is spend optimised, or has the infrastructure been built without attention to unit economics? Unmanaged cloud spend is a reliable indicator that operational discipline has not been established.",[79,171,172],{},"Backup and disaster recovery: what is the recovery time objective and recovery point objective? Has it been tested?",[38,174,175,177],{},[68,176,98],{}," No staging environment. Production is the first place any change is tested. This is not just a technical risk — it is a signal about how the engineering culture treats quality.",[48,179,181],{"id":180},"domain-4-security-posture-and-compliance-exposure","Domain 4: Security posture and compliance exposure",[38,183,184,186],{},[68,185,70],{}," What is the realistic exposure — regulatory, reputational, and operational — if this system is breached or found to be non-compliant?",[38,188,74],{},[76,190,191,194,197,200,203,206],{},[79,192,193],{},"Authentication and authorisation architecture. Is MFA enforced? Are permissions scoped by role?",[79,195,196],{},"Secret management: are API keys, credentials, and environment secrets stored securely (secrets manager) or in code or configuration files?",[79,198,199],{},"Data handling: what personal or sensitive data is stored, where, in what form, and under what retention policy?",[79,201,202],{},"Dependency vulnerability scanning: are known CVEs in third-party libraries being tracked and patched?",[79,204,205],{},"Penetration testing history: has the system been tested by an external party? When? What was found and remediated?",[79,207,208],{},"Regulatory landscape: GDPR, HIPAA, SOC 2, PCI-DSS — which apply, and what is the current compliance posture?",[38,210,211,213],{},[68,212,98],{}," Credentials committed to a git repository at any point in the project's history. If unrotated, those credentials remain actively exploitable by anyone with access to the repository or any of its clones. If rotated, the immediate risk is neutralised — but the exposure window between commit and rotation is unknown and unverifiable. More importantly, the commit is evidence of a process failure: the team did not have secret scanning, pre-commit hooks, or a secrets management policy in place at the time. Without explicit evidence those controls now exist, there is no basis to assume the pattern will not repeat.",[48,215,217],{"id":216},"domain-5-intellectual-property-and-licensing-risk","Domain 5: Intellectual property and licensing risk",[38,219,220,222],{},[68,221,70],{}," Does the company actually own what it is selling?",[38,224,74],{},[76,226,227,230,233,236],{},[79,228,229],{},"Employment and contractor agreements: do all individuals who have contributed to the codebase have proper IP assignment clauses? A contractor who contributed significant code without an IP assignment agreement is a potential ownership dispute waiting to surface.",[79,231,232],{},"Open source licence compliance: what open source libraries does the system use, and under what licences? GPL licences in a commercial product can create significant exposure.",[79,234,235],{},"Third-party IP: does the system incorporate any code, algorithms, or assets that were not created internally? Is there documentation of the right to use them?",[79,237,238],{},"Patent risk: for genuinely novel technical approaches, has any FTO (freedom to operate) analysis been done?",[38,240,241,243],{},[68,242,98],{}," Key early development done by a third-party agency with no IP assignment clause in the engagement contract. This is surprisingly common and can represent a material undisclosed risk.",[48,245,247],{"id":246},"domain-6-third-party-dependencies-and-vendor-lock-in","Domain 6: Third-party dependencies and vendor lock-in",[38,249,250,252],{},[68,251,70],{}," What happens to the system if a key third-party changes its pricing, deprecates its API, or goes out of business?",[38,254,74],{},[76,256,257,260,263,266],{},[79,258,259],{},"Dependency inventory: what services, APIs, and libraries does the system depend on? Is there a maintained inventory, or does this need to be reconstructed from the codebase?",[79,261,262],{},"Concentration risk: are there single-vendor dependencies for critical functions (payment, authentication, data storage, communication)?",[79,264,265],{},"Abstraction layers: are third-party integrations wrapped in internal interfaces that would allow a replacement to be swapped in? Or is the third-party API called directly throughout the codebase?",[79,267,268],{},"Contractual dependencies: what are the terms of key vendor agreements? Minimum commitments, data portability clauses, termination provisions?",[38,270,271,273],{},[68,272,98],{}," Direct integration with a single payment provider's SDK throughout the codebase, with no abstraction layer. Switching providers — whether due to pricing, a provider shutdown, regulatory requirements in a new market, or reliability failures — would require changes in dozens of places. The cost of switching is not visible in the business metrics until a forcing function makes it unavoidable, at which point it becomes urgent and expensive simultaneously.",[48,275,277],{"id":276},"domain-7-team-structure-and-knowledge-concentration","Domain 7: Team structure and knowledge concentration",[38,279,280,282],{},[68,281,70],{}," Is the technical capability of this business concentrated in one or two people who could leave — and what happens to the system if they do?",[38,284,74],{},[76,286,287,290,293,296,299],{},[79,288,289],{},"Bus factor: how many people would need to leave for critical technical knowledge to be lost? A bus factor of one is a risk that needs to be quantified and disclosed.",[79,291,292],{},"Documentation as knowledge distribution: is architectural knowledge in one person's head or in documentation that can onboard a replacement?",[79,294,295],{},"Succession readiness: is there a second-in-command who understands the system at the same depth as the lead engineer?",[79,297,298],{},"Retention risk: what are the current compensation, equity, and contract structures for key technical personnel? Are they likely to stay post-acquisition?",[79,300,301],{},"Hiring pipeline: does the team have a repeatable process for evaluating and onboarding technical hires, or has the team grown primarily through personal networks?",[38,303,304,306],{},[68,305,98],{}," The lead engineer who built the system has already left. The current team understands enough to keep it running but cannot extend the parts that matter — the core logic, the data model, the integration layer. Those sections are effectively frozen. New capability either gets built around the edges in ways that compound the existing fragility, or the team brings in someone external to rebuild the problematic components from scratch. Neither option is cheap, and neither is visible in the current velocity metrics. The deal terms should reflect that the technical asset has a ceiling the current team cannot raise.",[48,308,310],{"id":309},"domain-8-technical-debt-quantified-not-estimated","Domain 8: Technical debt — quantified, not estimated",[38,312,313,315],{},[68,314,70],{}," What is the actual cost, in engineering time and velocity, of the technical shortcuts that have been taken?",[38,317,74],{},[76,319,320,323,326,329],{},[79,321,322],{},"Debt inventory: has the team ever done a structured technical debt assessment? Do they have a maintained backlog of known debt items with estimated effort to address them?",[79,324,325],{},"Debt concentration: is the debt spread across the system, or concentrated in high-traffic, high-change areas where it will block every new feature?",[79,327,328],{},"Debt-to-feature ratio: roughly, what proportion of current engineering capacity goes to maintaining and working around existing debt versus shipping new capability?",[79,330,331],{},"Planned remediation: is there a credible plan to address the most impactful debt, with realistic timelines and resource allocation?",[38,333,334,336],{},[68,335,98],{}," The answer to \"what does technical debt cost you?\" is \"we handle it as we go.\" This means there is no inventory, no prioritisation, and no measurement — which means the debt is being accumulated faster than it is being addressed. Poorly managed technical debt consumes roughly 30% of a development team's capacity when left unaddressed. That is not a maintenance cost. That is a growth constraint that will show up in the next six months of velocity data.",[48,338,340],{"id":339},"how-to-use-this-checklist","How to use this checklist",[38,342,343],{},"Run it in sequence, but not in isolation. Each domain will surface questions that are answered in another — a team that has no incident post-mortems (Domain 3) is likely to also have no technical debt inventory (Domain 8) and no architectural decision log (Domain 1). The pattern of what is absent is as informative as what is present.",[38,345,346],{},"For a complete picture of what a technical assessment produces — findings, risk ratings, and the typical timeline for a properly scoped engagement — see our complete guide to technical due diligence.",[38,348,349],{},[129,350,351,352],{},"business2point delivers technical due diligence for investors, acquirers, and founders in three to seven business days. ",[353,354,356],"a",{"href":355},"\u002F#contact","Start the conversation →",{"title":358,"searchDepth":6,"depth":6,"links":359},"",[360,361,362,363,364,365,366,367,368,369],{"id":50,"depth":6,"text":51},{"id":63,"depth":6,"text":64},{"id":102,"depth":6,"text":103},{"id":144,"depth":6,"text":145},{"id":180,"depth":6,"text":181},{"id":216,"depth":6,"text":217},{"id":246,"depth":6,"text":247},{"id":276,"depth":6,"text":277},{"id":309,"depth":6,"text":310},{"id":339,"depth":6,"text":340},"Most technical due diligence checklists cover the obvious surface areas and miss the things that actually determine whether the technology can support the business thesis. This is the checklist we use.","md",{"date":5,"authorId":6,"category":7,"tags":8,"image":14,"readingTime":15,"published":16,"cluster":17,"post_type":18,"faq":19},"\u002Fblog\u002Ftechnical-due-diligence-checklist",{"title":33,"description":370},"blog\u002Ftechnical-due-diligence-checklist","6a1knX8MyhSlI4EiXbVgfSHy6PlDzQraQA3t4SSdRqo",{"id":378,"title":379,"body":380,"description":410,"extension":371,"meta":411,"navigation":16,"path":412,"seo":413,"stem":414,"__hash__":415},"content\u002Fcategories.md","Blog Categories",{"type":35,"value":381,"toc":408},[382,385],[38,383,384],{},"categories:",[76,386,387,390,393,396,399,402,405],{},[79,388,389],{},"id: strategy\nname: Strategy\ndescription: Technology strategy, CTO insights, and executive decision-making\nslug: strategy",[79,391,392],{},"id: engineering\nname: Engineering\ndescription: Software architecture, development practices, and technical deep-dives\nslug: engineering",[79,394,395],{},"id: ai\nname: AI & Automation\ndescription: Artificial intelligence, machine learning, and automation solutions\nslug: ai-automation",[79,397,398],{},"id: leadership\nname: Leadership\ndescription: Team building, engineering culture, and technical leadership\nslug: leadership",[79,400,401],{},"id: product\nname: Product\ndescription: Product development, user experience, and market-fit strategies\nslug: product",[79,403,404],{},"id: transformation\nname: Transformation\ndescription: Digital transformation, modernization, and scaling operations\nslug: transformation",[79,406,407],{},"id: due-diligence\nname: Due Diligence\ndescription: Technical due diligence, investment assessments, and acquisition readiness\nslug: due-diligence",{"title":358,"searchDepth":6,"depth":6,"links":409},[],"Categories for organizing blog content",{},"\u002Fcategories",{"title":379,"description":410},"categories","PTtAcQU13Is9QzoHEK0lkMj7seW0AClsgsBLpnB7qFs",1782472104505]