# Technical Due Diligence: What Buyers Should Check > Technical due diligence, step by step: what buyers and investors should check in code, infrastructure, team and security, and which findings change the deal. - Author: Filipe Eduardo, Senior Software Engineer (https://filipeeduardo.dev/) - Published: October 6, 2026 · Updated: October 7, 2026 - Topic: Legacy modernization · Tags: technical due diligence - Canonical URL: https://filipeeduardo.dev/blog/technical-due-diligence ![Open briefcase holding stacked code windows, one pulled out to reveal an orange crack beneath, depicting technical due diligence](https://cms.filipeeduardo.dev/wp-content/uploads/2026/10/technical-due-diligence-1.webp) ## Key takeaways - Due diligence checks that the product works the way the seller says. It is not a beauty contest for the code. - Use the same order I use for takeovers: access first, then the build, then the money paths, then the risks. - Ask to see things happen: a clean build, a deploy, a restore from backup. - Knowledge held by one person is often a bigger risk than messy code. - A useful report ranks findings and ties each one to price, deal terms or the roadmap. - IP ownership, licenses and compliance are legal questions. This article is not legal advice; involve a lawyer. Technical due diligence is a structured review of a software product’s code, infrastructure, team and security, done before you buy, invest in or merge with a company. The goal is to find out whether what you were told about the technology matches what actually runs in production, and what it will cost to keep it running and growing. As a rule of thumb (my estimate, not a market figure), a focused **technical due diligence** takes days to a few weeks and ends with a short report that ranks risks by their effect on price, terms and roadmap. Here is how I would run it, drawing on seven years of building products end to end and leading the live migration of a production platform to a new stack. ## What is technical due diligence, and who needs it? It is the technical part of checking a company before a transaction. It applies to acquisitions, investment rounds, mergers, and purchases of a product from an agency or a solo developer. It also fits founders who inherit a codebase after a developer leaves, because the question is the same: what exactly do we own, and what will it take to keep it alive? The people who usually need it: - Buyers acquiring a software company or a product. - Investors whose check depends mostly on the value of the software. - Founders and CTOs taking over a system from an agency or a departed engineer. - Companies about to merge two engineering teams or platforms. It is [broader and shallower than a code audit](https://filipeeduardo.dev/blog/code-audit). An audit reads code deeply. Due diligence covers code, delivery, infrastructure, security, people and contracts, and spends time in proportion to risk. If it finds a worrying area, a deeper audit of that area can follow. ## What does a technical due diligence process look like? Time-box it. The sequence matters more than the duration, and it mirrors [the first 30 days of a takeover](https://filipeeduardo.dev/blog/take-over-codebase-first-30-days). 1. **Access.** Ask for read access to the repositories, the cloud console, CI/CD, error monitoring, analytics, the domain registrar, app store accounts and third-party services. Check who holds each account: the company, an agency or an individual. If the seller cannot grant access in a reasonable time, that is already a finding. 2. **Build.** On a clean machine, follow only the written docs to build and run the product. Run the tests. Deploy to a staging environment if one exists. Note how long it took and what was missing from the instructions. 3. **Money paths.** Trace every flow that earns or moves money: signup, checkout, subscriptions, invoicing, payouts. Read the code, the tests and the error handling for each one. Working on the cart and checkout team at Total Wine & More taught me how much hides in the edge cases of these flows, so this is where I spend the most careful hours. 4. **Risks.** Only then go wide: security, dependencies, data, infrastructure, people and licenses. Finish by writing down what you could not verify. Unverified claims are risks too, and the report should say so. ## Which questions reveal the real state of the codebase? Sellers often describe the system as it was designed, not as it behaves. These questions force concrete answers, and the table shows what I listen for. Question Healthy answer Red flag Can a new engineer build and run it from the README? Yes, in hours, with documented setup Works only on one laptop; secrets shared in chat What happens when a payment fails or a webhook arrives twice? Handled safely, logged, retried Nobody knows, or it is fixed by hand Which parts does everyone avoid changing, and why? Specific parts with known reasons Vague answers or open fear of touching the code How do you deploy, and how do you roll back? Automated deploy, tested rollback Manual file copies, no rollback plan What tests cover the money paths? Some tests on critical flows, even if coverage is low None, or tests that are skipped or broken What is the oldest dependency, and when was the last upgrade? A known list with an upgrade history Runtime or framework versions no longer supported Three habits I rely on: - **Read the git history.** Who committed in the last year, how often, and are the authors of critical parts still around? - **Ask for the last production incident.** A team that can walk you through what broke, how they found it and what changed afterward is usually in better shape than one that says nothing ever broke. - **Read one money path end to end.** One hour in the checkout or billing code tells you more than a slide deck. ## How do you assess team, infrastructure and security risk? ### Team Leading more than 15 people across web, mobile and e-commerce taught me that knowledge in one head is the asset that decays fastest. Ask who understands each critical area, who is leaving, and what is written down. Check how code gets reviewed and how releases are decided. If the product was built by an agency or contractors, confirm who is under contract after closing. Whether the company actually owns the code written by them is a legal question, so ask a lawyer to review the agreements. For release practices, ask whether they use a [canary deployment](https://filipeeduardo.dev/blog/canary-deployment) to expose changes to a few users first. ### Infrastructure These are the items I check first: - Whether the cloud account belongs to the company, not to a former developer or agency. - Whether infrastructure is described in code or lives in someone’s memory and a console. If data moves between databases during a migration, ask whether [change data capture](https://filipeeduardo.dev/blog/change-data-capture) keeps both in sync. - Whether backups exist and, more importantly, whether anyone has restored one. Ask for a restore test. - Whether monitoring and alerts exist, and who gets paged. - Single points of failure, and the trend of the cloud bill compared with usage. ### Security You do not need a full penetration test to find the basics. Search the repository history for committed secrets. Check how authentication and authorization work, who has admin access, and whether former staff and contractors were removed. Run a dependency vulnerability scan and read the results with context. Review how personal data is stored and logged. If the backend relies on a hosted database with access rules, such as row-level security, check that those rules are actually enabled and tested. Compliance obligations such as privacy laws or customer security questionnaires belong with a lawyer or compliance specialist. ## What should a technical due diligence report include? Keep it short enough that a non-engineer can act on it. A useful structure: - **Summary and verdict.** Two paragraphs: is the product what the seller claims, and what are the top risks? - **Scope.** What was reviewed, how, and what could not be verified. - **System overview.** Stack, hosting, third-party services, and a simple architecture sketch. - **Findings ranked by severity.** Each with evidence (a file, a screenshot, a failed step), not opinion. - **Effort estimates.** Ranges, clearly labeled as estimates, for fixing the main findings. - **People dependencies.** Who holds critical knowledge and what happens if they leave. - **First 30 and 90 days.** What to do right after closing. - **Open questions for the seller.** Items to resolve before signing. Avoid unexplained scores out of ten. A decision-maker needs to know what each finding means, what it costs and what to do next. ## What findings should change the deal or the roadmap? ### Findings that change the deal - The seller does not control the assets: code, domain, cloud account or app store listing sits with a third party. - Revenue flows cannot be verified, or the money paths are broken in ways users have not noticed yet. - An undisclosed security incident or exposed customer data. - Possible licensing problems in the code or dependencies, to be confirmed by a lawyer. - The whole system depends on one person who is not staying. Depending on severity, responses can range from a lower price to conditions that must be met before closing, holdbacks, or walking away. How to structure those terms is a question for your lawyer, not for an engineer. ### Findings that change the roadmap Most findings do not kill a deal. They reshape the first quarter: unsupported frameworks, missing tests on critical flows, manual deploys, no restore-tested backups. [Fix the safety net first, then change the product.](https://filipeeduardo.dev/blog/legacy-modernization) If the findings point toward replacing the stack, resist the instinct to plan a rewrite. A rewrite usually costs more and takes longer than an incremental migration, because the old system must keep running in parallel. I prefer to [put a switch in front of everything before writing new code, then move the system piece by piece while it stays live](https://filipeeduardo.dev/blog/strangler-fig-pattern). That is how I approached leading the full migration of a platform that applies to job openings automatically while its users kept using it every day. ## Want a second opinion on your case? If you are about to buy, invest in or inherit a product, email me@filipeeduardo.dev with the stack and what is at stake, and I’ll tell you what I’d check first. ## Frequently asked questions ### How long does technical due diligence take? It depends on the size of the system and how fast the seller grants access. My rule of thumb is one to two weeks for a small product and longer for larger ones. Slow access is itself a signal. ### How much does it cost? I do not know of a published market range I would trust, so I will not quote one. Compare the cost with the size of the deal and the cost of a surprise after closing, and ask for a fixed scope and a written deliverable. ### Can a non-technical buyer do it alone? Partly. You can verify account ownership, ask for demos of the build and a backup restore, and request the incident history. For code, security and architecture, bring in an independent senior engineer who has no stake in the deal. ### What if the seller will not share the code? Treat it as a red flag. Alternatives are an NDA with a supervised screen-share session, a review by a neutral third party, or restricting access to the money paths and security-sensitive parts. If none is accepted, price in the uncertainty. ### Does an AI-built codebase need different checks? The method is the same. When I look at one, I put extra weight on access rules in the database, secrets, tests on the money paths and whether anyone on the team can explain how the code works.