The Orange Problem

Ten years ago an investor told me I had a mess in my head. He was right, and it took me a decade and a crate of oranges to see exactly what kind of mess it was.

A scale where there wasn't one

The oranges aren't mine — I heard the case at a workshop from someone who built it at Microsoft. A produce grower had people standing over a packing line making a call on every fruit: green ones can travel to Seattle, orange ones stay in Florida. Two states. That was the entire resolution of the system, because that is the resolution of a human eye that has been looking at oranges since six in the morning.

They put a vision model on the line. It read the surface of the fruit and gave a number: days remaining before spoilage. Not two buckets — a scale. And a scale is a different kind of object than a bucket. You can put a scale into a logistics calculation. You can route on it, price on it, decide on it.

What struck me wasn't the model. It was that nobody in that company had been asking for AI. They had a shipping loss problem, and the loss came from a measurement that didn't exist. The technology mattered only because it produced the missing number.

The KPI that doesn't work

I ran into the same wall from the opposite side, at scale, with a government.

Part of my work as CIO — Kyrgyz Single Window is the AI direction for national customs systems. At some point we had to answer a reasonable-sounding question: what are the KPIs for our AI services?

Every intuitive answer is wrong, and wrong in an instructive way. Number of AI systems deployed — you get systems nobody uses. Share of processes touched by AI — you get AI inserted into processes that were fine. Adoption percentage — you get adoption theater. All of these measure the technology's spread, and the technology's spread is not a benefit to anyone.

The useful question turned out to be much smaller and much harder: which specific, named, expensive task got cheaper?

I found my answer in a conversation, not in a planning document. An officer at the Ministry of Economy described a task that was eating hours of his week and hours of his colleagues' weeks. He wasn't pitching a project; he was complaining. Listening to that one complaint produced ai.trade.kg — a working tool that removed that specific task.

That is a KPI you can defend: hours, on a named process, before and after. It is also, not coincidentally, the only kind of AI project I have seen survive contact with an organization.

What falls out when you build for one problem

Here is the part I didn't expect.

When you build AI for a named problem inside a regulated organization — a customs system, a law firm, a clinic — the constraints stop being obstacles and start being the architecture. The data cannot leave the perimeter, so the model runs on their hardware. The answer has to be verifiable, so every claim cites the document chunk it came from. Nobody will act on a machine's output unmediated, so an operator approves anything above a threshold, and the threshold belongs to the client, not to me.

Build that way for a while and look at what the system has accumulated on its own: a record of every decision and the rule that produced it, a log of who approved what and when, the exact sources behind every answer, snapshotted so they survive the deletion of the original document.

That is an audit trail. Nobody asked for it. It is a by-product of the system doing its job, because the system cannot do its job without leaving a trace.

Meanwhile there is a whole market forming above this layer: AI registries, control planes, assurance certifications, evidence packs. Real products solving a real problem — enterprises deploying agents nobody is tracking. But look at what they have to do. They sit on top of systems that were never designed to be accountable, and they compile accountability afterwards, by hand, from the outside.

I have started calling the alternative assurance by construction, as opposed to assurance by attestation. Not a governance layer added to a product. A product whose architecture cannot run without producing the evidence. The distinction matters most exactly where it is hardest to fake: an organization of three hundred people will never hire a certification body, but it will happily accept an audit trail that writes itself.

The same mistake, in my own house

Then I looked at my own website.

Eight items in the navigation. A homepage that said I was exploring how LLMs and interfaces fit together. A sovereign AI platform for law firms sitting in the same grid as a second-hand gear marketplace and a pixel roguelite. A services page priced by the hour, which tells every serious buyer that they are looking at a pair of hands.

It was the adoption-percentage KPI, applied to a career. Lots of surface, no named problem. I had been doing to myself precisely what I tell clients not to do.

There is a line I keep coming back to, and it is not from technology at all — it's from an old advertising principle: you have to make every single detail perfect, and you have to limit the number of details. The second clause is the hard one. Adding is pleasant. Cutting is what produces clarity.

And clarity is the whole commercial mechanism. A confused mind says no. Not "maybe" — no. If the person across the table cannot repeat back what you do, they will not buy it, whatever it costs and however good it is.

The offer, stated once

So: one sentence, and everything else in service of it.

I build AI systems for organizations whose data cannot leave the perimeter.

Law firms, clinics, customs authorities, family offices — teams that cannot paste their work into a cloud chatbot. The engagement starts with thirty minutes on what actually wastes your team's week, and one legitimate outcome of that conversation is don't build this yet, in writing, with reasons.

Underneath, three layers I'd separate deliberately, because they answer different questions:

• What I sell is a solution. Not a technology, not a transformation program. A named problem, removed.
• How it's packaged is convenience. Ready systems running in your own contour, instead of hiring a team to build them.
• Why it's me is experience — how the work feels: no jargon, no theater, a working prototype instead of a deck, and a straight answer when the answer is no.

The oranges, the ministry, and my own homepage are the same lesson at three scales. AI is not something you adopt. It is something you point at one expensive problem, precisely enough that you can tell afterwards whether it worked.

Everything else is surface area.