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.
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.
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."
The first step is understanding what exists. Ask:
The answers will reveal:
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.
Internal tools are often written quickly and informally. Adjust expectations, but don't ignore critical issues:
What matters:
What you can accept:
What's critical to fix:
Internal tools often integrate with core business systems — and those integrations are frequently the most fragile part:
Map every integration. For each, understand: what happens if it breaks? Who knows how to fix it?
Beyond the code, understand how the operations team actually uses these tools:
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).
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.
Acquiring a company and concerned about inherited internal tooling? Contact us — we assess internal tool landscapes as part of acquisition due diligence, identify operational risks, and create the remediation plan before you close.
If this guide resonated with your situation, let's talk. We offer a free 30-minute discovery call — no pitch, just honest advice on your specific project.
Your developer went silent. Your project is half-built. You don't know what state the code is in. This is the step-by-step guide to recovering your project and getting back on track.
10 min readRescuing SoftwareHow enterprise buyers should evaluate SaaS vendor security — what certifications actually mean, what to look for in security questionnaires, data residency requirements, incident response, and the contract clauses that protect you.
11 min read