Demo or system? How to tell before you pay, or before you launch
A demo proves an idea can work once; a system keeps working with real data, real users and real mistakes. What a demo hides, the signs of a real system, and the questions to ask before you pay or launch.
A good demo is exciting. Someone types a question, the screen answers, everyone in the room nods. Whether you’re about to approve a budget or about to launch something you built yourself with an AI tool, that moment feels like proof. It is proof of one thing only: the idea can work once, under good conditions.
A system is something different. It keeps working on a Tuesday afternoon when the data is messy, a user does something odd and nobody from the team is watching. The gap between the two is where most of the cost and most of the risk live. Here is how to see it before it costs you.
What a demo hides
A demo is like a show home: furnished, clean, perfectly lit. You can’t tell from the tour whether the plumbing works. Five things are usually missing behind the walls:
- Only the happy path. The demo follows the route the builder knows works. Real users take every other route too: they leave fields blank, paste a whole email into a name box, click the button twice.
- Sample data. Ten tidy records, chosen to look good. Your real data has duplicates, missing values, old formats and the odd record nobody can explain.
- No errors. When an outside service is slow or the AI gives a strange answer, what happens? In a demo, it simply never comes up.
- No users. One person, one screen. Not fifty people at once, each allowed to see different things.
- No security. Passwords in the code, no logins, everything open, because it was “just a demo”. That’s fine for a demo and dangerous for anything with real customers.
None of this means the demo was dishonest. Demos are useful: they show whether an idea is worth pursuing. The trouble starts when a demo is sold, bought or launched as if it were finished.
Signs you’re looking at a real system
You don’t need to read code to spot these. You only need to ask to see them.
- Real data. It has run on your own data, or a realistic copy, not a hand-picked sample. Ask what broke the first time it did.
- Tests. Tests are small automatic checks that confirm the software still does what it should after every change, like the checklist a pilot runs before every flight. Ask what they cover and when they run.
- Monitoring. Monitoring means the system reports on its own health: errors, slow responses, unusual costs. Without it, the first person to notice a problem is a customer.
- Failure handling. There is a plan for when things go wrong: a clear message to the user, a retry, a hand-off to a person. Ask to see what happens when the AI service is unavailable.
- Someone responsible. A named person or team who gets the alert, fixes the problem and answers your call. A system nobody owns slowly turns back into a demo.
Questions to ask before you pay, or before you launch
If someone is selling you the work, ask them. If you built it yourself with an AI tool, ask yourself, and ask the tool too: it will often list what it skipped if you ask directly.
- What happens with data that is messy, missing or wrong?
- What happens when the AI gives a wrong or strange answer? Who would notice, and how?
- What happens when an outside service is down?
- Who can log in, and what can each person see and change?
- Where are the passwords and keys kept?
- How do we know it still works after a change?
- How will we hear about a problem before a customer tells us?
- Who is responsible once it’s live, and what does that cost per month?
Good answers are specific and a little boring: “errors go to this dashboard and alert this person.” Vague answers, like “it’s pretty robust” or “we’ll handle that later”, tell you that you’re still looking at a demo.
A demo isn’t the problem. Pricing it as a system is.
Turning a demo into a system is normal work, and often it’s most of the work. The honest version of the conversation sounds like this: “This proves the idea. Making it safe for real users means adding these pieces, and it will take this long.” If you hear that, you’re talking to someone who knows the difference. If the price and the timeline assume the demo is nearly done, expect surprises after launch, and expect to pay for them then.
Checklist: demo or system?
- Has it run on real or realistic data, not only a sample?
- Can someone show you what happens when something fails?
- Are there automatic tests, and do they run on every change?
- Does the system alert someone when errors or costs jump?
- Are logins, permissions and secrets handled properly?
- Is a named person responsible after launch?
- Does the price or plan include the work to get from demo to system?
Written from our engineers’ work on production systems. Want a second opinion on your project? Talk to an engineer.
See the work →