Demo Debt

Apparently it is a podcast image?

Demo Debt

Martijn Veldkamp

Martijn Veldkamp

Published Oct 30, 2026

+ Follow

“But it worked in the demo”. I think that sentence deserves a place next to “it is only a small change” in the enterprise technology hall of fame. Possibly engraved on something expensive.

Imagine a team showing an AI assistant to a leadership group. It finds a customer, summarises the account and drafts a useful response. The room gets excited, as always somebody asks when it can be rolled out. Someone else mentions it in a planning meeting. And before you know it, a week later the prototype has a delivery date.

Applause has dependencies

A demonstration selects what people see. That is the job, you have a few minutes to make an idea understandable, so you prepare the data, choose a coherent happy flow journey and avoid spending half the meeting resetting passwords while praying to the demo gods.

There is nothing dishonest about that, provided everyone understands what the demonstration proves. A prototype can prove that an interaction is useful or that an integration is possible or even how different screens and their flows may look. It probably will tell you very little about access control, operating cost, recovery or why a customer name occurs in 6 different systems.

My point is that the audience often carries away an implicit and broader conclusion than what you wanted to show or even what the evidence supports. They saw the assistant answer a question, so they believe the service is (almost) ready. The team saw a promising experiment with several hard questions still open. Both leave pleased, which makes the misunderstanding surprisingly durable.

Then the screenshot appears in a strategy deck

I would call the resulting obligation demo debt. It is the work and political difficulty created when a demonstration becomes a promise before its actual limits have been understood. The prototype can be beautifully written and still create this debt, partly because everybody has their own expectations.

The happy path gets promoted

Take that hypothetical assistant. It uses a privileged account because identity was outside the experiment. It has 20 prepared and groomed documents because the question was whether RAG could help. A developer restarts it manually because running overnight was not part of the test.

Those choices can be completely sensible. However, now the team must replace the privileged account, establish ownership of the documents, handle those pesky permissions and arrange support. The demo still works, so each item sounds like finishing detail. Together they may constitute most of the actual service. Like the old school Pareto principle.

And because the organisation has already announced the benefit, explaining the gap can actually sound like retreat. The architect becomes the person slowing things down. The security reviewer becomes the person who does not understand innovation. The developer who built the exciting thing is asked why they cannot just make it production ready.

Swedish Chef could probably explain this situation better than the status report. Bork, bork, access control.

I have written about the Feature Factory and its habit of measuring output. Demo debt starts a little earlier, when that persuasive picture of output acquires funding and a date before anybody has agreed what success actually looks like.

A useful experiment can end

My opinion is that demonstrations need a clear question and an explicit next decision. If the question was whether users understand the interaction, report what you learned about that. If the experiment leaves uncertainty about the economics, say so while everyone is still looking at the screen.

That does not require 40 warning slides before showing anything interesting. It can be a plain sentence: this version uses prepared data, the next iteration is necessary to prove whether it works with real permissions and representative demand.

Then give the next stage a budget and a stopping condition. A team should be able to discover that an idea is attractive but too expensive to operate without being accused of failing to deliver something it never promised.

Developers benefit because the temporary shortcuts remain visible. Architects can distinguish questions already answered from assumptions still being tested. Business sponsors get a more useful investment choice than “we have come this far, might as well finish”. And ooh boy, does that last thing happen often.

One of the risks is that your program portfolio fills with commitments whose strongest evidence is a successful presentation. The organisation starts funding the defence of earlier enthusiasm, and useful experiments become compulsory deliveries.

I still want the demo. Show me the thing, let people get excited and find out whether the idea has legs. Just leave room for the next discovery to change the decision.