The demo is the product

The 30-second proof

We bring a QR code to events. Someone scans it, enters a question on their phone, and within seconds the answer appears on a screen behind us — synthesised from our internal docs, rendered in our voice, cited with real sources. No laptop. No "let me show you a slide about our capabilities". The system is running. You just used it.

That demo does more work than any brochure we could write. It proves we can ship. It proves the output quality. It proves we understand latency, error states, and what happens when someone types "lol test" into the form. You don't have to trust our claims about RAG pipelines or prompt engineering — you just watched it work.

Three jobs, one artefact

A good demo is a sales tool, obviously. Prospects see a working system instead of a capability matrix. But it does two other things most agencies ignore.

First, it's a recruiting filter. Engineers who care about craft want to see what you actually build, not your Dribbble portfolio. When a candidate asks "what does good look like here?", we can point at a real system with real constraints: sub-3-second response time, graceful degradation when the LLM chokes, a UI that doesn't assume everyone has read the manual. If they're unimpressed, we've saved everyone six months.

Second, it's a case study that runs live. Most case studies are retrospectives — past tense, sanitised, no way to verify the claims. Ours is present tense. The system is running right now. The code is in a repo. The logs are real. When we say "we built a citation system that links back to source paragraphs", you can try to break it.

What's scripted, what's not

We're not pretending this is magic. Some parts are scaffolded:

• The question form has a character limit. We're not handling novel-length queries.
• The doc set is fixed. We're not re-indexing Wikipedia every night.
• The prompt has been tuned. We didn't ship the first draft that hallucinated our founding date.
• The error states are designed. If the LLM times out, you see a message, not a stack trace.

But within those bounds, it's genuinely live. No canned responses. No Wizard of Oz. If you ask something we've never been asked before, the system has to figure it out with the same retrieval and generation loop it uses every time. We've had people try to trick it, ask it about competitors, submit queries in German. Sometimes it fails. That's fine. The demo isn't a magic trick — it's a representation of what the system can do under real conditions.

Why agencies don't do this

Most consultancies don't ship demos because demos are expensive. You have to build a real system, host it, handle traffic spikes, fix bugs, keep dependencies up to date. It's easier to make a slide deck.

But that's the point. The difficulty is the signal. If you can't ship a small, scoped system for your own use case, why should anyone believe you can ship a large, complex one for theirs? The demo is a forcing function. It makes you confront the same problems your clients will confront: latency, cost, quality, maintenance.

We treat our demo the way a product company treats their landing page. It's not a side project. It's not a hackathon leftover. It's infrastructure. We version it, monitor it, iterate on it. When something breaks, we fix it, because the demo breaking means our positioning breaks.

What this means for you

If you're evaluating AI consultancies, ask to see a working system. Not a prototype. Not a screen recording. A URL. Something you can use right now, ideally something they use themselves. If they can't show you one, they're selling a capability they haven't internalised.