At Eyeweb, the eyewear technology company where I was CTO, we wrote our software for one network and it failed at another. It worked fine at a large optical retailer in New York and failed at one in Paris. We had written it for a Novell network on Ethernet, and the Paris network was Token Ring, a different topology. I had to rewrite the database calls. The software was developed under assumptions that were no longer true there.
A deal arrives with a good demo. The sponsor is credible, the founder is sharp, and the software works in the room. For a family office without a technical team of its own, that is often where the diligence on the technology ends.
It should be where it starts, because every demo works. That is what a demo is for. The useful question is what happens when the problem is ten times larger, or when something the software assumed stops being true.
Here is the shape of the problem. A delivery van has ten stops and any order is allowed. Trying every order means checking about 3.6 million routes. Twenty stops is about 2.4 quintillion. At a billion routes a second, that is roughly 77 years of work for one machine. Each stop you add multiplies the work.
Computers got faster by many orders of magnitude, and the hardware bought a handful of extra stops. What let a fleet route thousands of stops was mathematics: shortcuts that find a good route without trying every order. Faster chips did not move the wall. Better methods did.
Every one of those shortcuts works because it assumes something: that the roads behave, that the pieces are independent. Most of the time the assumption holds. When it does not, the software still returns an answer, and the answer is confidently wrong.
Three Mile Island is the sharp version. In 1979 operators trusted an indicator that reported what a valve had been told to do, not what the valve was doing. The indicator was an abstraction of the valve. The valve was stuck open.
So the technical question on a direct investment or a co-investment is not "does it work?" The demo answers that. Ask three things, in plain terms, of the sponsor or the founder:
- Which side of the wall does this problem sit on? At the size the plan says it will reach, is the problem still easy, or does the work multiply with each added piece?
- Which shortcut gets it across? What method makes the large version possible, and who on the team can explain why it works?
- What does that shortcut assume, and what does it hide? An assumption that held at ten customers may not hold at ten thousand.
A demo shows the small version, where everything is fast and the assumptions hold. A plan fails on the large one, or on the day an assumption does. Someone on your side of the table should be asking, before the capital is committed, which day that is.
This is the author's account and is not investment advice.
Sources and notes
- Where the Wall Is, Troy M. Pearsall, DoAyni, 2026: the delivery-route example and the shortcut question. https://doayni.com/analysis/where-the-wall-is
- The route counts (3,628,800 orders for ten stops, about 2.4 quintillion for twenty) are 10 and 20 factorial; the 77 years assume a billion routes a second, one route per step. Author's arithmetic.
- Three Mile Island, March 1979: the control-room light showed that the relief valve's solenoid was powered, not that the valve was shut, and the valve stayed stuck open for more than two hours. The Nuclear Accident at Three Mile Island: Day 1, Three Mile Island Alert. https://www.tmia.com/wednesday (secondary account).
- The Eyeweb paragraph is the author's own account from his time as the company's CTO; the retailers are not named.