Trade secret valuation: pricing the know-how inside your code

Trade secret valuation runs on replacement cost, income attribution and comparables. How to inventory your business rules and build the evidence buyers ask for in diligence.

Know-how gets priced at the diligence table, not on the software line of the balance sheet

Trade secret valuation comes down to three calculations, and any serious appraiser will ask for all three: what it would cost to rebuild the thing from scratch today, how much margin you lose if it leaks or disappears, and what someone paid for something comparable in a real transaction. Replacement cost, income attribution, market comparables. When the know-how lives inside your codebase, replacement cost is the only one you can run on your own next week, because the inputs are already in the building: how many live rules you have, how many senior hours it would take to rewrite them, and how long discovery takes for everything nobody ever wrote down.

The second part is what actually moves the number, and it is where most founders lose money. It runs on evidence. A trade secret only counts as an asset if you can show it was secret and still belongs to you: who had access, under which contract, in which repository, with which log. Without that, the appraiser does not write zero on the spreadsheet. He writes a risk discount, and that discount usually costs more than the refactor you postponed for two years.

The three calculations an appraiser will accept

Of 1,043 branches in the pricing service, 34 changed in a year: those are the ones that count

• Replacement cost: estimate the senior engineering hours needed to reach the same behaviour, starting from a team that has never seen the system, and multiply by a real blended rate. That figure is the floor, never the ceiling.
• Income attribution: isolate the margin that exists because of that rule and would not exist without it, such as the discount policy that protects repeat purchases or the risk model that lets you approve credit faster than the competition, then project it across the years the rule should hold.
• Market comparables: look at what acquirers paid for the intangible portion in deals in your sector, which in practice means the gap between transaction value and the book equity of the company acquired.

A finished valuation usually blends all three, weighted toward income attribution. But the one you can start today, without hiring anyone, is replacement cost. It has a useful property too: if replacement cost is low, the rest of the conversation will be short, and you want to find that out before you sit across the table from a buyer.

Count the branches before you write any number

I opened a pricing service and counted the decision points: 1,043 branches across if statements, switches and parameter tables. Then I laid twelve months of change history on top, and 34 of them had actually been touched, roughly 3% of the total. Those 34 are the living business. The other 1,009 are frozen history, decisions made by people who left, rules from campaigns that ended, exceptions for accounts that no longer exist.

That split is the entire basis of the calculation. You do not value 1,043 branches. You value the 34 that move, plus the subset of frozen ones that still decides money every month without receiving maintenance. The rest is a liability dressed as an asset, because every dead line raises the cost of touching a live one.

I have written before about where those thousand rules should live, whether in code, in a rules engine or in the finance team's spreadsheet. That piece uses the same count to decide architecture. Here it does something else: it becomes a line in a valuation. Same measurement, different question.

"It is already capitalised on the balance sheet as software"

On site, a section is only signed off with as-built drawings. Software works the same way

That objection shows up in every meeting with finance, and it is half right. What got capitalised is development cost, amortised over a period someone picked years ago. That measures what you spent, not what it is worth. The two only match by accident.

The gap becomes visible in diligence. A buyer never asks what you spent. He asks whether buying the company also buys the knowledge, or whether he is buying a system that three people can explain and two of them have no confidentiality agreement in place. In the US, information only qualifies as a trade secret if you took reasonable measures to keep it secret, and reasonable measures means paperwork: restricted access with logs, signed agreements with everyone who saw it, a repository the company actually controls.

Here is the uncomfortable part. In a lot of rescue work, the main repository still sits in a personal account belonging to the previous vendor, with his production key still active. I covered that in detail when I wrote that your old vendor is still logged into production. For valuation purposes the effect is blunt: know-how a third party can read without an NDA is not a secret. It is shared information, and it prices accordingly.

As-built drawings are worth more than the structure standing up

When I was the responsible engineer for steel structure assembly, nobody signed off on a section just because it stood up. Acceptance came with the as-built drawings, the test reports, the material traceability. A structure without that stack of paper is an expensive problem, not an asset.

Software works the same way, and the documentary evidence that holds up a price comes in four shapes:

• Commit history where the message explains the decision, not just the diff. It is the one document nobody manages to leave un-updated.
• Architecture decision records, even ten lines per decision, saying what was considered and what was rejected.
• Tests that describe the rule in business language and fail when the rule changes. A test without an assertion is the opposite of that: it exists for the coverage report, not for the buyer.
• Versioned parameter tables outside the code, with effective dates, so yesterday's rule stays auditable after today's goes live.

Those four do two jobs at once. They raise income attribution, because they prove the knowledge transfers, and they cut the key-person risk discount. It is the opposite of code that passes the pitch and fails diligence, where a polished screen hides that nobody remembers why that 7% discount is there.

The price shows up on its own the day you switch vendors

If you want to know what the knowledge trapped in your system is worth without hiring an appraiser, there is a brutal field test: ask an outsider to reimplement one live rule without talking to whoever wrote it. However long that takes is your real replacement cost, and it includes the part no spreadsheet predicts, which is the archaeology before the first new line.

That cost collapses or explodes depending on who is on the other side. A vendor who swapped the team between the proposal and the kickoff starts the archaeology from zero, which is why I argued that the team they sold you is not the team that delivers. To turn hours into money without guessing, use a public rate reference, or a monthly cost of a dedicated development team divided by billable hours. A sourced number survives an audit. An invented one does not.

One short detour, worth the paragraph: I have seen a company find out, during a vendor exit, that its most valuable rule lived in a spreadsheet an analyst maintained by hand, and the system only read it. The asset existed. It just was not where everyone assumed.

Where this calculation is worth nothing

Commodity logic has no value. Tax computation, carrier freight tables, instalment rounding: the whole market has those, and a competent appraiser strikes them out on the first read. What survives is the rule you only know because you got burned, the policy that came out of a real loss, the adjustment that exists because one specific customer broke in one specific way.

I also cannot tell you whether any of this applies to a three-person company a year into trading. At that stage the knowledge is still intact inside the founders' heads, and the buyer is buying the founders, not the repository. The calculation starts to matter when the system outlives the people who wrote it, which is exactly the moment most companies discover it does not.

Start with the 34 rules that changed

Block out forty minutes this week and do the boring part: list the rules that decide price, discount, commission and credit limits, and mark which ones changed in the last twelve months. For each one that changed, write a single line explaining why it exists and who can explain it without opening the code.

If you cannot fill that second column for more than half the list, your valuation number is already decided, and it is not the one you had in mind. The question to bring to your next board meeting is short: of the rules that make the most money here, how many would keep running and stay understood if the two people who touch them most both left in the same month?