AI DEMOS

How to Spot a Fake AI Demo: 7 Signals

The 7 signals we check in every AI demo before buying or building, each with the exact question that breaks it. No form, no signup.

PUBLISHED August 4, 2026 · 7 min read

By ACME
Editorial

Don't trust any AI demo. Including ours.

Not out of professional skepticism — that pose is as empty as the hype it complains about. I say it because we build demos. I know exactly how much can hide inside three well-rehearsed minutes, because I've been on the other side of the cable picking the example that looked best.

A demo is, by definition, a happy path with the lights on. One request, good wifi, the case someone chose after trying twenty. Production is the exact opposite: real traffic, dirty data, two people hitting the same button at once, and a timeout on a Tuesday afternoon.

These are the 7 signals we've collected over the years. No single one proves anything. Three together do. Each comes with the exact question that breaks it, so you don't need to be technical to use it.

Signal 1 · The demo always uses the same example

The same contract, the same fictional customer, the same invoice. If you watch two demos from the same company a month apart and the case is identical, that's not tidiness — it's the only case that runs without surprises.

A real system is indifferent to the example. A tuned demo isn't: it was polished against that input until it came out clean.

The question: "Can we run it right now, on one of my cases?"

Bring an ugly one on purpose. A crooked scanned PDF, a customer whose name was typed wrong, an order with two duplicate line items. What happens in the next thirty seconds tells you more than the rest of the meeting.

Signal 2 · It never fails

Every system that actually exists fails. An API goes down, a field comes back in a shape nobody planned for, an external service takes eight seconds. Forty minutes of demo without a single error doesn't mean the system is solid — it means you're being shown the one part where there aren't any.

What you want to see isn't the absence of failure. It's what it does when it fails: whether it tells someone, whether it retries, whether it leaves the process half-done or in a state you can resume.

The question: "Show me what happens when the call fails."

Signal 3 · There isn't a single log in sight

AI you can actually operate leaves a trail: what it received, what it decided, what it based that on, how long it took, what it cost. If a boring screen full of text lines never appears in the entire demo, there's a real chance it doesn't exist.

This is the most uncomfortable signal, because logs are the least sellable thing on earth. Nobody applauds an event table. Which is exactly why it's the hardest one to fake.

The question: "Where do I see what the agent did when I'm not watching?"

Signal 4 · "We'll connect that later"

The most expensive sentence in software, and it almost always shows up right when the conversation gets near your real systems: your ERP, your CRM, your billing, the spreadsheet the whole operation quietly depends on.

The promise isn't the problem. The problem is that the integration is the project. The pretty part — a model answering well — is something plenty of people can do now. The hard part, the part that eats the months, is making it read from and write to systems nobody documented and nobody can turn off on a Tuesday.

The question: "Which part of what you just showed me is connected to a real system today, and which part is a mockup?"

Signal 5 · You're rushed to sign

A discount expiring Friday, implementation slots filling up, prices going up next month. It might all be true. But commercial urgency and technical solidity almost never travel together: someone with a system that works loses nothing by waiting three weeks, because the system will still work in three weeks.

The rush is usually covering one of two things: a sales number, or the fact that the thing doesn't exist yet and they need your deposit to build it.

The question: "What exactly changes if I sign in three weeks?"

Signal 6 · It can't survive two clicks

This is the house favorite, and the one that produces the strangest faces. Press the button twice in a row. Submit the same order twice. Kill the wifi halfway through and retry.

In a demo that never happens, because nobody rehearses the error. In production it happens every day: someone double-clicks, a connection drops, the system retries after a timeout. If that action was a charge, you now have a customer billed twice who finds out before you do.

The property that prevents this is called idempotency: the same action, carrying the same identifier, does not execute twice no matter how many times it arrives. It's an ugly word, and it's exactly the line between a system and a brand-new problem with better marketing.

The question: "Can I press the button twice?"

Signal 7 · They can't show it running

The last one contains the other six. A pre-recorded video instead of a live screen. A slide with the architecture instead of the product. A success story from a client who can't be named, with a number that can't be audited.

Each of those can have a legitimate reason on its own — real NDAs exist, real sensitive data exists. But when every reason points the same way, and no version of the product can be touched, the simplest explanation is usually the right one.

The question: "Can you show it running, on my data, on a call?"

How to use this without becoming insufferable

This isn't an interrogation. It's a thermometer. One signal on its own means nothing: it could be a rushed demo, a non-technical seller, a young product that still does the job.

Our rule: three signals together and we stop. We don't end the relationship or accuse anyone — we ask for a second meeting with someone who wrote the code. If that meeting doesn't exist, or gets postponed twice, the question has already been answered.

And one honest caveat: almost none of this is bad faith. Most of the time it's an excited team showing what they want to be true in six months. The illusion isn't the problem. The problem is that you pay for it today.

Point it at us too

Everything above applies to ACME the same as to anyone else. If we show you something and you can't press it twice, don't buy it.

That's why we don't open with a proposal. We open by picking oneof your processes and measuring it for thirty days: what goes in, what comes out, what it costs. At the end there's a real number on the table, and if that number can't be defended on a call, we don't continue. Neither of us.

If someone showed you a demo recently and it left you uneasy, tell me about it. I'll tell you in one line whether it clears the checklist.

~/subscribe

Get the next posts

1-2 emails per month with notes on AI velocity, MVPs, and B2B operations. Unsubscribe anytime.

~/start-project
GOT A DEMO THAT FELT OFF?
START A CONVERSATION