There are only two ways anyone prices software. What it earns, or what it cost to make.
The first one needs revenue. The second one just died.
A three-month build with AI assistance can now embed what used to take a team two years: a dozen integrations, a trained model, a compliance posture, an actual working product. Cost and capability have come apart. So "we spent $400,000 building this" has stopped being an argument about value. It's an argument about how you chose to spend money.
Which leaves a real problem. Somewhere between "no revenue yet" and "obviously worthless" sits an enormous amount of working software — side projects that shipped, internal tools that outlived their department, platforms whose company pivoted. It works. People used it. It never made money. Every marketplace that might sell it prices on a revenue multiple, so the number comes out at approximately zero, and the thing gets switched off instead.
I think that's a pricing failure rather than a value failure. Here's the test I use instead.
The 90-Day Test
Could a competent competitor, with unlimited AI tooling and $50,000, reach this exact position within 90 days?
If yes, the asset has close to no moat — however good the code is.
If no, then something specific is stopping them. That blocker is the thing you're actually buying. Everything else is packaging.
The important word is position, not product. The test is not "could this be built." In 2026, almost anything can be built. The question is whether the position can be reached — the product plus everything true about the world around it.
Run that against real assets and only four blockers survive.
Time
Calendar months that can't be compressed. A domain with fifteen years of history, a dataset that took three years to accumulate, a brand people already recognise. Money and compute do not age a thing. This is the only moat AI cannot touch at all.
Permission
Somebody else has to say yes. A payment licence, SOC 2, a marketplace approval, a hospital procurement cycle, a regulator. Approval queues are not an engineering problem, and you cannot parallelise them by hiring.
Data
Records that exist only because the thing actually ran. Real user behaviour, real failure cases, real edge conditions. Synthetic data is not data — it's an assumption with good grammar.
Embedment
Users and systems that already depend on it. Four integrations built against your API means four teams who'd have to do work to leave. Distribution remains the hardest thing on earth to rebuild.
Notice what's missing. Code quality isn't on the list. Architecture isn't on the list. Neither is how clever the thing is. Those made the list when building was the expensive part. It isn't any more.
A worked example
Below is a composite, assembled from the shape of real assets rather than describing any single one — a B2B platform, no meaningful revenue, sold because the team moved on.
It cost $250,000 to build: ten months, two engineers, roughly $125/hour of competent time. That number is real and verifiable. It is also, as we'll see, almost irrelevant.
The number that isn't irrelevant is what reaching that same position costs today: about $180,000. Not because the team overpaid, but because eighteen months of tooling improvements happened underneath them. Call it Time-to-Position — the cost of the months of market entry a buyer skips, priced at today's rates rather than the ones that were charged. Every figure below is anchored to that, not to the receipt.
Scoring the four blockers, 0–25 each:
| Blocker | Score | Why |
|---|---|---|
| Time | 13 / 25 | Ten months of market entry genuinely skipped. Real, but ten months is not fifteen years. |
| Permission | 6 / 25 | SOC 2 Type II held — but nothing else. No licence, no regulator, no approval anyone must wait for. |
| Data | 16 / 25 | A genuine flywheel exists. It is also entirely undocumented, which means a buyer inherits it without knowing how to operate it. |
| Embedment | 19 / 25 | Four third-party integrations built against the API, on annual contracts. Leaving costs those customers real work. |
Moat score: 54 / 100.
Now read it. The strength is embedment — other people's systems are wired into this thing, and that's expensive to unpick. The weakness is permission: a 6 means a funded competitor faces no approval barrier whatsoever. They don't need to wait for anyone. They just need to decide to start.
That single number reframes the whole asset. It isn't "defensible software." It's software with real switching costs and no gate — which is a fundamentally different thing to own, and a different thing to pay for.
A moat of 54 carries a multiple of 0.85×–1.50× against Time-to-Position. On $180,000, that lands the band at $153,000 – $270,000, midpoint about $211,500.
Now put the three numbers side by side.
| Spent building it | $250,000 |
| Cost to reach that position today | $180,000 |
| What it's worth | $211,500 |
It is worth less than it cost to make. Not because the engineering was bad — it wasn't. Because three of the four things that actually protect a position are weak, and no amount of good code compensates for a permission score of 6. The $250,000 is a receipt, not an argument.
And it is worth more than it would cost to rebuild. That gap — $211,500 against $180,000 — is the moat, priced. It is what the four integrations and the undocumented data flywheel are actually worth: about $31,500 over the cost of standing the thing up from scratch. Not nothing. Not the $70,000 the team feels they lost, either.
Both readings come out of the same test, and the second one is the reason to run it. A framework that always returns a flattering number isn't a valuation method, it's a sales brochure. One that can only ever disappoint you isn't either — it's just pessimism with a table.
The part sellers hate
The same test cuts the other way, and this is where it earns its keep.
An asset can look modest — small codebase, unglamorous problem, no revenue — and score high, because it spent four years accumulating a dataset nobody can replicate, or holds a licence with an eighteen-month approval queue. Under a revenue multiple, that asset prices at zero. Under this test, it's the most defensible thing on the board.
The corollary is uncomfortable if you're selling: a beautiful, sophisticated, technically excellent platform that any competent team could stand up in a quarter is worth roughly what it costs to stand up in a quarter. The sophistication was never the moat. It just used to be expensive, and we mistook the expense for a barrier.
AI didn't destroy the value of software. It destroyed the value of building software — and those were never the same thing. We just never had to tell them apart before, because the cost of building was high enough to hide behind.
Now it isn't. So we need a test that asks what's actually in the way.
I run Day Xero, a managed M&A platform for pre-revenue and early-revenue tech assets. The full method — including the parts I've compressed here — is in the valuation guide, and there's a free scored estimate at dayxero.xyz/adr if you want to run something of your own through it.
Top comments (0)