Secrets and credentials exposure
API keys, passwords, tokens, certificates, or shared credentials accidentally committed to repositories or left inside unmanaged systems.
Technical diligence for acquisition decisions
Before you acquire the business, understand the technology you are inheriting.
I help searchers, operators, and investors evaluate whether software, systems, automation, infrastructure, documentation, and technical ownership create real advantage — or hidden post-close risk.
Operator-led reviewFocused on what happens after close, not just what looks acceptable in a repository.
Legacy-awarePractical experience around old stacks, awkward systems, unusual dependencies, and scarce specialists.
Delivery capacityBacked by experience building and running a near-100-person software delivery business.
Why this matters
Financial diligence tells you what happened. Technical diligence helps you understand what may happen after close.
In many small and lower-middle-market acquisitions, technology is treated as an operational detail. That is dangerous when the business relies on proprietary software, custom integrations, automation, embedded systems, or one technical person who knows how everything works.
1
Separate advantage from custom complexity
Proprietary technology is not automatically a moat. Sometimes it is defensible know-how. Sometimes it is expensive maintenance debt with a good story around it.
2
Expose transferability risk
The question is not only whether the system works today. It is whether a new owner can safely operate, support, improve, and staff it after close.
3
Turn findings into post-close priorities
The output should help you make a better acquisition decision and understand the first 30, 60, and 90 days of technical work after closing.
Common findings
Examples of what technical diligence can uncover.
A focused review should connect technical findings to ownership risk, transition risk, remediation effort, and post-close execution priorities.
Key-person dependency
Critical systems, deployment knowledge, vendor relationships, or recovery procedures owned by one person with limited documentation.
Licensing and IP gaps
Open-source license exposure, unclear contractor assignment, personal email commits, or missing ownership records for important code.
Unsupported legacy systems
Old frameworks, abandoned migrations, custom integrations, or technologies that are hard to hire for and expensive to maintain.
Security and dependency risk
Known vulnerable dependencies, missing patch processes, weak access control, poor backup discipline, or fragile recovery procedures.
Execution and transition risk
Slow release cadence, undocumented deployment steps, unclear ownership, poor observability, and weak handover readiness after close.
What gets reviewed
The repository is only part of the story.
A useful review looks at the technical asset, the people around it, the operating model, and the risks that may not appear in the CIM or financials.
Product & architecture
System structure, dependencies, scalability limits, upgrade path, technical debt, and whether the software actually supports the business model.
Legacy & specialist risk
Older languages, scarce skills, undocumented tooling, fragile build processes, and whether maintainers can realistically be found after close.
Operations & reliability
Deployment process, backups, monitoring, incident response, infrastructure maturity, support burden, and operational survivability.
Team & knowledge transfer
Key-person dependency, documentation quality, ownership clarity, tribal knowledge, technical leadership gaps, and transition risk.
Security & access control
Identity management, secrets handling, privileged access, auditability, recovery posture, and basic safeguards expected from a business-critical system.
Automation & AI exposure
Where automation is useful, where it is fragile, and whether AI-generated or low-governance systems introduce hidden maintenance risk.
Especially useful when
The business is not “a software company”, but technology still affects the deal.
These are often the situations where technology risk is underestimated: industrial equipment, field service, healthcare, logistics, manufacturing, B2B services, niche platforms, or old businesses with custom systems that quietly run the operation.
A
The seller claims proprietary software is a competitive advantage
We pressure-test whether that claim creates pricing power, operational advantage, customer lock-in, margin improvement, or only future cost.
B
The current technical owner is critical
If the software lives in one person’s head, the deal may depend on retention, incentives, documentation, and a realistic transition plan.
C
The technology touches hardware or field operations
Embedded and industrial systems require looking beyond code: hardware interaction, calibration, installation, support, manufacturing process, and field failures matter.
Typical output
A clear view of technical acquisition risk.
The review is designed to produce an executive summary, critical findings, risk classification, transferability concerns, post-close priorities, and suggested deep-dive areas. The goal is not a giant theoretical report. The goal is a sharper acquisition decision.
Why Safyron
Operator judgement, not checklist theatre.
Safyron is led by Ilian Madzharov, a former software engineer and technology executive who co-founded and scaled a software delivery company to nearly 100 people. The review is grounded in practical ownership questions: what will break, who understands it, who can maintain it, and what the buyer must do next.
1
Discovery first
Scope depends on the deal, access, technology footprint, stakeholder availability, and how much confidence the buyer needs before close.
2
Specialists when needed
For legacy, embedded, Delphi, Lotus Notes, industrial, or uncommon stacks, the right expert matters more than a generic code review.
3
Post-close realism
If problems are found, the next question is execution: what to stabilize, what to defer, what to replace, and what must be transferred before the seller exits.
Start here
Book a focused discovery call.
Bring the messy version: what the seller claims, what worries you, what access you have, who currently owns the technology, and what decision you need to make.
Good fit
When the acquisition depends on technology you do not fully understand.
Not every deal needs deep technical diligence. But if software, systems, automation, data, infrastructure, or one critical technical employee can affect revenue, service delivery, customer retention, or post-close execution, ignoring it is reckless.