Code quality and security debt in software

In a software business the code is the product and the main asset. Buyers tend to judge it by what they can see, such as a working product, growing revenue and low churn. The cost of owning it depends on what they cannot see: how easily it can be changed, how well it is tested, how current its components are and how exposed it is to attack.

Technical debt behaves like a liability that never appears in the accounts. Shortcuts taken to ship features, frameworks that no longer receive updates and code only the founder understands all become spending after you buy. The first year's plans can turn into a rebuild while growth stalls. Security debt can be worse, because its bill may arrive as a breach: lost customer data, possible duties to notify regulators and customers, and the cancellations that follow.

The profit in the listing may also be flattered. A founder who writes the code without a market salary, or who has put off upgrades and security work, is running the business below its true cost. A realistic view of earnings includes a market cost for engineering plus the catch-up work the product needs. SDE shows what the business earns for an owner who does that work. If you plan to hire someone instead, adjusted EBITDA is the better guide, and the Loupe valuation tool calculates it by subtracting a market salary for the owner's role from SDE.

For anything beyond a small app, an independent code and security review before you commit is usually worth its cost. Use what it finds in the price and in the warranties you ask for.

• One founder or one contractor wrote most of the code, and nobody else has deployed it.
• The product runs on language versions, frameworks or libraries that no longer receive security updates.
• There are few automated tests, and releases are made by hand.
• Some parts of the system are avoided, or new features have slowed while bug reports rise.
• Passwords and keys are stored in the code repository, or live customer data is used for testing.
• There is no recent penetration test, or findings from the last one remain open.
• Incident logs or support tickets show repeated outages or data problems.
• Hosting costs rise faster than customer numbers.

• Who wrote the code, who can deploy it today, and who else has access to the repositories and live systems?
• Which languages, frameworks and major components are used, and when were they last upgraded?
• How much of the code has automated tests, and how are releases made and reversed?
• Have you had any security incidents, breaches or suspicious access? How were they handled, and who was told?
• When was the last penetration test or security review, and what remains unresolved?
• What would you fix or rebuild first if you were staying?
• Which open source licences apply to the components the product uses?

• Read-only access to the code repositories, including commit history
• An architecture overview and a list of third-party services and hosting providers
• A scan of third-party components showing versions, known vulnerabilities and licences
• Penetration test and security review reports, with evidence of fixes
• Incident logs and uptime records for the last 24 months
• Hosting and infrastructure invoices for the last 12 months
• Agreements assigning code ownership from every developer and contractor
• Backup and disaster recovery procedures, with the date they were last tested