You have found a business worth buying. The financials look solid. The customer base is real. The revenue is recurring. And somewhere underneath all of it sits a software system you have never seen — custom-built, possibly years old, maintained by someone who may or may not still be around.
That software is not just a line item on the asset sheet. It is the operational backbone. It processes orders, manages data, serves customers, connects systems. If it is healthy, you inherit a foundation you can build on. If it is brittle, you inherit a liability that will consume your first year of ownership in unplanned rebuilds.
This is where technical due diligence earns its keep — not as a formality, but as the difference between acquiring a business and acquiring a problem.
Why Financial Due Diligence Is Not Enough
Most acquisition due diligence focuses on the balance sheet, the customer contracts, the legal exposure. That makes sense. But when custom software is central to how the business operates, a financial audit alone leaves a dangerous blind spot.
Software does not depreciate in the way accountants model it. A codebase can look like it is worth something on paper while being one dependency update away from a cascade of failures. Revenue can be strong today while the system generating it is unmaintainable tomorrow.
The risk is not abstract. Consider what happens when you close a deal and then discover:
- The application runs on a framework that has been end-of-life for two years, with no security patches available.
- There are no automated tests, so every change requires days of manual verification.
- The only person who understands the deployment process left six months ago and did not document it.
- Customer data is stored in ways that do not meet current regulatory requirements.
- The hosting bill is three times what it should be because the infrastructure was never right-sized.
None of these show up in a P&L. All of them show up in your first quarter of ownership.
The Technical Due Diligence Checklist
What follows is the framework we use at FigTree Development when helping someone evaluate a codebase before buying a business. It is not exhaustive — every acquisition has its own shape — but it covers the areas where hidden cost and hidden risk concentrate.
1. Architecture and Stack Assessment
Start with the big picture before touching a single file. You need to understand what the system is built from, how the pieces connect, and whether the technology choices are still viable.
- Language and framework versions: Are they current, supported, and actively maintained by their communities? End-of-life frameworks are not just a technical nuisance — they are a security and hiring liability.
- System architecture: Is it a monolith, microservices, or something in between? How are services connected? Are there integration points with third-party systems, and are those integrations documented?
- Data layer: What databases are in use? Are schemas documented? Is there a clear data model, or has the schema evolved organically without a plan?
- Infrastructure: Where does the application run — cloud, on-premise, hybrid? Who controls the accounts? Are there infrastructure-as-code definitions, or was everything configured manually through a console?
The goal here is not to judge whether the original team made good choices. It is to map the terrain so you can estimate the real cost of maintaining and evolving the system after close.
2. Code Quality and Maintainability
A working application and a maintainable application are not the same thing. Software can function perfectly today while being nearly impossible to change safely tomorrow.
- Test coverage: Does the codebase have automated tests? What percentage of the code do they cover? More importantly, are the tests meaningful — do they test business logic and edge cases, or are they superficial checks that pass no matter what?
- Code organization: Is the code structured in a way that a competent engineer can navigate without tribal knowledge? Are there clear separations of concern, or is business logic scattered across layers?
- Technical debt inventory: Every codebase has debt. The question is whether it is managed or ignored. Look for patterns: duplicated code, hardcoded values, TODO comments that are years old, suppressed warnings.
- Documentation: Not just comments in the code, but architectural decision records, API documentation, runbooks for common operational tasks. The absence of documentation is itself a finding — it means knowledge lives in one or two heads, and those heads may not transfer with the deal.
3. Security and Compliance Posture
Security gaps in acquired software become your gaps the moment you sign. And depending on the industry, they can become regulatory violations with real financial consequences.
- Authentication and authorization: How do users log in? How are roles and permissions managed? Are there hardcoded credentials anywhere in the codebase or configuration?
- Data handling: How is sensitive data stored, transmitted, and accessed? Is encryption applied at rest and in transit? Are there data retention policies, and are they enforced technically or just written in a policy document?
- Dependency vulnerabilities: Run a software composition analysis. How many known vulnerabilities exist in third-party libraries? How old are those libraries? A project with dozens of unpatched dependencies is a project that has not been actively maintained.
- Compliance requirements: If the business handles health data, financial data, or personal data in regulated jurisdictions, does the software meet the applicable standards? This is not a checkbox exercise — it requires understanding what the software actually does with that data at the code level.
4. Deployment and Operations
How the software gets from source code to a running production system tells you more about operational maturity than almost anything else.
- Deployment process: Is there a CI/CD pipeline, or are deployments manual? How long does a deployment take? Can it be rolled back if something goes wrong? Manual deployments are not just slow — they are error-prone and impossible to scale.
- Environment parity: Are there separate development, staging, and production environments? Do they mirror each other closely enough that a test in staging is meaningful?
- Monitoring and observability: Once the application is running, can anyone tell if it is healthy? Are there alerts for failures, performance degradation, or resource exhaustion? Or does the team find out about problems when a customer calls?
- Disaster recovery: Are there backups? Have they been tested? Is there a documented recovery plan, and has it ever been exercised? A backup that has never been restored is a hope, not a plan.
5. Team and Knowledge Concentration
This one sits at the intersection of technical and human factors, and it is where acquisitions most often stumble.
- Key-person risk: How many people understand the system deeply enough to fix a critical production issue at 2 AM? If that number is one, and that person is not part of the acquisition, you have a problem that no amount of code review can solve.
- Knowledge transfer plan: Is the seller willing to provide a transition period with the existing technical team? What does that look like in practice — weeks of pairing sessions, or a handoff document written the day before close?
- Hiring implications: Given the technology stack, how difficult will it be to hire engineers who can work in this codebase? A system built on a niche or outdated framework shrinks your talent pool significantly.
What a Software Audit Actually Looks Like in Practice
A thorough technical due diligence engagement is not someone glancing at a repository for an afternoon. It is a structured process — the same kind of discovery and architecture work that should precede any significant technical decision.
At FigTree, that process starts with understanding the business context: what the software does, who depends on it, and what the acquirer plans to do with it after close. A codebase that needs to run as-is for five more years requires a different evaluation than one that will be replaced within twelve months. The assessment has to be grounded in the buyer's actual intentions, not an abstract notion of code quality.
From there, the work moves into the technical layers outlined above — architecture review, code analysis, security scanning, infrastructure audit, operational assessment. The output is not a pass/fail grade. It is a detailed map of what you are inheriting: what works well, what carries risk, what will cost money to address, and how urgent each item is.
That map becomes a negotiation tool. It informs the purchase price. It shapes the transition plan. It gives you a realistic budget for year one. Without it, you are estimating in the dark.
When to Walk Away
Not every finding is a deal-breaker. Technical debt is normal. Imperfect documentation is common. Missing tests can be written. Outdated libraries can be updated.
But some patterns should give you genuine pause:
- No source code access: If the seller cannot or will not provide access to the codebase before close, that is not a red flag — it is a closed door. You cannot evaluate what you cannot see.
- Single point of failure with no transition: If one person holds all the knowledge and they are leaving with no overlap period, you are buying a system you cannot operate.
- Fundamental architectural misalignment: If the software was architected for a use case that no longer matches the business, or if scaling it to meet your growth plans would require a near-total rewrite, the acquisition math changes dramatically.
- Unresolvable compliance gaps: If the software handles regulated data in ways that cannot be remediated without a ground-up rebuild, the compliance risk may exceed the business value.
Walking away from a deal is expensive. But closing a deal without understanding the technical foundation is almost always more expensive.
The Soil Work Happens Before the Signature
Technical due diligence is not glamorous work. It does not produce a flashy slide deck or a catchy metric. It produces clarity — a grounded, honest picture of what sits beneath the surface of a business you are about to make your own.
That clarity is the foundation everything else gets built on. The integration plan, the first hire, the first product improvement, the first year of growth — all of it is shaped by what you learn in the weeks before close. Skip the soil work, and you spend your first season pulling weeds instead of planting.
If you are evaluating a business acquisition and the software is a black box you have not opened yet, that is exactly the kind of problem we help with at FigTree Development. We are a small, purpose-driven firm — not a big consultancy running a generic checklist. We bring real architectural experience to the table: the kind that comes from years of building, integrating, and operating the systems that businesses depend on.
It starts with a conversation, not a pitch. Book a free 20-minute discovery call and let us help you understand what you are really buying — before you sign.