# Technical Due Diligence for Internal Tools: What to Check Before You Inherit Them — Hunchbite > How to evaluate internal tools before acquisition, team transition, or major investment — the specific risks of operationally-critical systems with no external customers, minimal documentation, and high bus factor. Source: https://hunchbite.com/guides/technical-due-diligence-internal-tools [Home](https://hunchbite.com/)/[Guides](https://hunchbite.com/guides)/[Rescuing Software](https://hunchbite.com/guides/topic/fix-my-software)/Technical Due Diligence for Internal Tools: What to Check Before You Inherit Them [Rescuing Software](https://hunchbite.com/guides/topic/fix-my-software) # Technical Due Diligence for Internal Tools: What to Check Before You Inherit Them How to evaluate internal tools before acquisition, team transition, or major investment — the specific risks of operationally-critical systems with no external customers, minimal documentation, and high bus factor. By HunchbiteMarch 12, 20269 min read due diligenceinternal toolsacquisition > **Internal tools** are the unsexy infrastructure of acquisitions. Nobody puts them in the pitch deck. But when you acquire a business, you acquire its operational software — and internal tools that break post-close can halt operations faster than any external product failure. When evaluating a company for acquisition, most buyers focus on the customer-facing product. Internal tooling — order management dashboards, operations trackers, custom ERP integrations, internal reporting systems — gets mentioned in passing if at all. This is a mistake. Internal tools are often the most business-critical software in the company, operated by non-technical users who can't troubleshoot failures, and understood by a single developer who may be leaving. ## Why internal tools are a disproportionate acquisition risk **No external pressure to maintain them:** Consumer products get bug reports. Internal tools get workarounds. Users learn to avoid the broken button, export to Excel and manipulate the data manually, or just stop using the feature. The tool appears functional while quietly failing. **Built for current business, not future business:** Internal tools are often built to solve the problem as it exists today. Post-acquisition, the business changes. Volume doubles. Workflows change. The internal tool, built for the previous state, becomes a bottleneck or breaks entirely. **Owned by whoever built them, not by the business:** The person who built the tool carries context that isn't in the code. When they leave — which is more likely post-acquisition — that context leaves with them. **No SLA, no monitoring, no incident process:** When an internal tool goes down, there's often no alerting. Users notice, use a workaround, and log a ticket that nobody prioritizes because "it's internal." Hunchbite Service #### Technical Due Diligence Independent technical assessment for investors, acquirers, and founders — a report you can put in front of a board. [Request due diligence](https://hunchbite.com/technical-due-diligence) ## Inventorying the internal tool landscape The first step is understanding what exists. Ask: 1. What software does the operations team use that isn't a commercial off-the-shelf product? 2. What would stop working if the main developer left tomorrow? 3. What spreadsheets or manual processes exist because a tool doesn't do something it should? 4. What has broken in the last year and how was it fixed? The answers will reveal: * Tools you didn't know existed * Workarounds that indicate broken or missing functionality * Hidden dependencies on specific people ## The bus factor assessment For each internal tool identified: | Question | Green | Red | | ------------------------------- | -------------------- | ----------------------- | | Who built it? | Still at the company | Left or leaving | | Who can deploy updates? | 2+ people | 1 person | | Is there documentation? | Runbook exists | Nothing written down | | Who supports it when it breaks? | Helpdesk process | "Call \[name\]" | | Is the code in version control? | Git repo, reviewed | Local files, no history | A tool that scores red across the board is a liability. You need a remediation plan before close, not after. ## What to actually look at in the code Internal tools are often written quickly and informally. Adjust expectations, but don't ignore critical issues: **What matters:** * Is there a database? Are there backups? (Internal tools with no backups and years of operational data are a ticking clock) * Is authentication in place? Can any employee access any record? * How does the tool integrate with other systems? Are those integrations documented? * What happens when the tool fails? Is there a fallback process? * Can a new developer make changes without breaking things? **What you can accept:** * No automated tests (almost universal in internal tools) * No CI/CD (often fine for low-change-frequency tools) * Minimal code comments (less ideal but workable) * Simple, direct code style (often easier to maintain than over-engineered systems) **What's critical to fix:** * No data backups for operational data * No access control (all users can read/write everything) * Undocumented integrations with production systems * A tool that processes financial data with no audit trail Hunchbite Service #### Code Audit Services An independent, written assessment of code quality, security, and architecture — with prioritised, actionable fixes. [Request a code audit](https://hunchbite.com/code-audit-services) ## Integration risks Internal tools often integrate with core business systems — and those integrations are frequently the most fragile part: * **Direct database connections** to production databases — a bug in the internal tool can corrupt production data * **Undocumented API calls** to external services using API keys that may expire or be rate-limited * **File-based integrations** where a manual export/import process is a critical step in a workflow * **Email or SMS automations** that trigger business processes — who controls the sending account? Map every integration. For each, understand: what happens if it breaks? Who knows how to fix it? ## Operations team dependency mapping Beyond the code, understand how the operations team actually uses these tools: * Which users rely on this tool daily for their job function? * What training exists for new employees? * What manual steps exist alongside the tool? (Spreadsheets, printed reports, email workflows that complement the tool) * How would operations continue if the tool were unavailable for 48 hours? The answers reveal whether the tool is a productivity enhancer (can live without it temporarily) or an operational critical path (can't function without it). If you're staring at a portfolio of undocumented internal tools owned by people who may not stay, [we can map this risk for you before you close →](https://hunchbite.com/technical-due-diligence) ## Post-acquisition planning For each internal tool, decide pre-close: | Category | Decision | Action | | ------------------------ | -------------------------- | ---------------------------------------------------- | | Critical, well-built | Maintain and improve | Budget for ongoing development | | Critical, poorly built | Stabilize then modernize | Immediate remediation + replacement roadmap | | Critical, undocumented | Document before transition | Require seller knowledge transfer as close condition | | Non-critical, functional | Leave as-is | Monitor, low priority | | Non-critical, broken | Evaluate replacement | Replace with off-the-shelf if possible | **The most dangerous category:** Critical + poorly built + owned by a leaving developer. This is the combination most likely to cause an operational crisis in the 90 days post-close. ## Deal structure for internal tool risk * **Knowledge transfer requirement:** Make the primary developer available for 60–90 days post-close at a specified number of hours per week * **Documentation condition:** Require operational runbooks for each critical internal tool before close * **Escrow holdback:** If a specific tool is critical and undocumented, hold a portion of the deal price until documentation is complete and verified * **Remediation budget:** Budget for immediate internal tool stabilization in the post-acquisition plan — typically ₹5L–₹20L depending on complexity --- ## Need this done for you? Internal tools are the most underdocumented and most operationally critical part of any acquisition. Hunchbite assesses internal tool landscapes as part of acquisition due diligence — operational risk identification, bus factor analysis, and a remediation plan with cost estimates so you know what you're inheriting before you close. **[→ Technical Due Diligence Service](https://hunchbite.com/technical-due-diligence)** Call [+91 90358 61690](tel:+919035861690) · [Book a free call](https://cal.com/hunchbite/discovery) · [Contact form](https://hunchbite.com/contact) Ask an AI assistant about this guide: [ChatGPT](https://chatgpt.com/?q=Read%20https%3A%2F%2Fhunchbite.com%2Fguides%2Ftechnical-due-diligence-internal-tools%20and%20help%20me%20apply%20it%20to%20my%20situation.%20Answer%20my%20questions%20about%20it.&hints=search) · [Claude](https://claude.ai/new?q=Read%20https%3A%2F%2Fhunchbite.com%2Fguides%2Ftechnical-due-diligence-internal-tools%20and%20help%20me%20apply%20it%20to%20my%20situation.%20Answer%20my%20questions%20about%20it.) · [Perplexity](https://www.perplexity.ai/search?q=Read%20https%3A%2F%2Fhunchbite.com%2Fguides%2Ftechnical-due-diligence-internal-tools%20and%20help%20me%20apply%20it%20to%20my%20situation.%20Answer%20my%20questions%20about%20it.) On this page * [Why internal tools are a disproportionate acquisition risk](#why-internal-tools-are-a-disproportionate-acquisition-risk) * [Inventorying the internal tool landscape](#inventorying-the-internal-tool-landscape) * [The bus factor assessment](#the-bus-factor-assessment) * [What to actually look at in the code](#what-to-actually-look-at-in-the-code) * [Integration risks](#integration-risks) * [Operations team dependency mapping](#operations-team-dependency-mapping) * [Post-acquisition planning](#post-acquisition-planning) * [Deal structure for internal tool risk](#deal-structure-for-internal-tool-risk) * [Need this done for you?](#need-this-done-for-you) Ask AI about this guide * [Open in ChatGPT](https://chatgpt.com/?q=Read%20https%3A%2F%2Fhunchbite.com%2Fguides%2Ftechnical-due-diligence-internal-tools%20and%20help%20me%20apply%20it%20to%20my%20situation.%20Answer%20my%20questions%20about%20it.&hints=search) * [Open in Claude](https://claude.ai/new?q=Read%20https%3A%2F%2Fhunchbite.com%2Fguides%2Ftechnical-due-diligence-internal-tools%20and%20help%20me%20apply%20it%20to%20my%20situation.%20Answer%20my%20questions%20about%20it.) * [Open in Perplexity](https://www.perplexity.ai/search?q=Read%20https%3A%2F%2Fhunchbite.com%2Fguides%2Ftechnical-due-diligence-internal-tools%20and%20help%20me%20apply%20it%20to%20my%20situation.%20Answer%20my%20questions%20about%20it.) FAQ Why does internal tooling need technical due diligence? Internal tools are often the operational backbone of a business — they run order management, track inventory, process payroll, manage customers, or control production. When you acquire a company, you inherit its internal tooling. If those tools break post-acquisition, operations break. The fact that internal tools have no external customers doesn't make them less critical — it often makes them more so. What is the most common problem with acquired internal tools? They were built by someone who no longer works there. Internal tools are typically built by a developer who understood the business deeply, wrote the code to solve their specific problems, and documented nothing. When that person leaves, the tool becomes a black box that the operations team depends on and nobody truly understands. Should internal tools be replaced or maintained post-acquisition? Evaluate on a case-by-case basis. A tool that is deeply embedded in operations and has years of institutional logic is often cheaper to maintain and improve than to replace. A tool that is poorly built, brittle, and blocking growth is a candidate for replacement. The due diligence should clarify which situation you're in before close. Independent acquisition due diligence ## Find the operational landmines before you close. Hunchbite assesses internal tool landscapes as part of acquisition due diligence — bus factor analysis, integration risk, and a remediation plan with cost estimates. You know exactly what you're inheriting before the deal is signed. [Technical Due Diligence](https://hunchbite.com/technical-due-diligence)[Get a Free Code Audit](https://hunchbite.com/audit) Trusted by VMAC Industries, TKD Logistics, Astitva Jewellery & more. [See our recent work →](https://hunchbite.com/case-studies) Fixed-price, no hourly billing · No obligation · We tell you upfront if we're not a fit Continue Reading [Rescuing SoftwareThe Seller's Guide to Technical Due DiligenceHow to prepare your software for technical due diligence as a seller — what buyers will check, what kills deals, what to fix before access is granted, and how to present your technology confidently.11 min read](https://hunchbite.com/guides/sellers-guide-technical-due-diligence) [Rescuing SoftwareTechnical Due Diligence for SaaS Acquisitions: An Investor's GuideHow to evaluate the technology behind a SaaS acquisition — what to check beyond the standard code review, how findings affect ARR multiples, and what makes SaaS tech a strong or weak asset.12 min read](https://hunchbite.com/guides/tech-due-diligence-saas-acquisition) [All Guides](https://hunchbite.com/guides)