2026  ·  5 min read

The Customer Doesn't Audit the Supply Chain

A nineteen-year-old jogging around the block with a few euros in his hand learned something that most boardrooms arguing about proprietary AI still haven't figured out: the customer is buying the plate, not the kitchen.

The brief

The menu had gyros on it. We didn't make gyros.

When I was nineteen, I worked in a restaurant in Greece for a summer. The menu had gyros on it, which was a problem, because we didn't actually make gyros. What we had was a kiosk around the corner that did.

So when a table ordered one, I'd take off my apron, jog around the block, hand over a few euros, jog back, and plate it in the kitchen like it had come off our own spit the whole time. Nobody at the table ever knew. Nobody asked. They got a hot gyros, on time, on one of our plates, and as far as they were concerned that was the whole story.

The floor

What they were actually buying.

It worked because the thing they were actually buying wasn't "a gyros made on these premises." It was a good gyros, delivered without friction, while they sat at our table with their friends. The kiosk, the jog, the handoff in the kitchen — none of that was the product. It was infrastructure. Invisible by design, and rightly so.


The reframe

The same instinct, with more money behind it.

Years later, a different scene played out: sitting in on a meeting at a food delivery startup, watching two departments argue like it was a deleted scene from Silicon Valley. The trigger was mundane: a driver had a flat tire mid-delivery. The proposed fix was to route that order through a competitor's delivery network so the customer still got their food on time.

I expected at least some hesitation about handing business to a rival. There wasn't any. The answer came back flat:

"Yes. Whatever it takes to please the customer."

It's the same move I was making at nineteen, just institutionalised and with real stakes attached. The company didn't care whose driver, whose app, or whose logo touched the order along the way. They cared whether the customer's experience held up. Pride in "we do this ourselves" lost to "the customer doesn't know and shouldn't have to care."


The build

Where this shows up now.

I'd suggest the more interesting version of this argument is happening in boardrooms right now, around AI.

A lot of executive energy currently goes into questions like: did we build this model ourselves, is our AI proprietary, are we "just" a wrapper around someone else's API. Those are legitimate questions — they matter for cost structure, defensibility, and risk exposure, and a CEO should be asking them.

But they're internal questions. They're about your supply chain, not the customer's experience of the plate. The person using the product isn't evaluating whether your AI is "real" by some architectural standard. They're evaluating whether their problem got solved, reliably, at a price and speed that makes sense. A well-orchestrated wrapper that consistently delivers a good outcome will beat a proprietary model that doesn't, every time, in the market that actually pays the bills.

That's not an argument for indifference to what's under the hood. Build-versus-buy decisions have real consequences for margin, lock-in, and long-term defensibility, and getting them wrong is expensive. It's an argument for keeping those questions in the right place. They belong in your cost models and your risk reviews. They don't belong in the customer's experience of your product, and they shouldn't be the thing that decides whether a leadership team feels good about what it shipped.

The customer never audited how the gyros got to the plate. They audited the plate.

Worth remembering the next time a room full of smart people is arguing about the kiosk, and nobody's asked yet whether the customer even knows it exists.

AI strategy Product CTO thinking Build vs buy