Technical Due Diligence for Internal Tools: What to Check Before You Inherit Them

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."

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

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).

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

Call +91 90358 61690 · Book a free call · Contact form