A demo is a recorded route. The data is selected, the volume is small, the path runs from one button to the next, and everything on it has worked at least once before - otherwise nobody would be showing it. That is not a deception, it is the nature of a demonstration.
The problem starts the moment a demonstration turns into an acceptance test. It is signed off as working, the invoice goes out, and the first real data arrives afterwards. The gap between what the customer saw and what happens on Monday morning is then treated by nobody as a defect - it is treated as extra work.
This text is about how to set up acceptance so that the gap comes out before anything is signed.
The demo will fail. It should fail at the supplier, not at you
We will start with our own experience, because it is an unpleasant one.
On 6 August 2026 our demonstration failed at a client. Our own note from that day reads, word for word: "wherever I clicked, it was either a fault or an error", and generating the document took about ten minutes. This was a system that prepares contract documentation - work where somebody puts their signature under the output.
Four days later, on 10 August 2026, the same system was demonstrated to the client's whole office and the stage was invoiced. Between those two days neither the brief nor the scope changed. What changed was that the first run had happened for real and found what needed finding.
Only one practical rule follows, and it applies to anyone including us: the first real run has to happen somewhere. The only question is whether it happens at the supplier, on your data, before signature - or at your end after it.
Volume is a different problem from a demo. And it shows in the first week
The second example is from our own product, so we can describe it concretely. The Jobsi system for staffing agencies has a module that reads passports and vehicle documents from a photograph.
We chose the technology on 29 November 2025 and we chose the more expensive one. We turned down cheaper machine recognition because of what those photos actually look like: people take them handheld, in a car, behind the wheel. In the demo it worked.
It went into real use on 17-19 February 2026. On 23 February 2026 clients complained that scanning was slow and failing with an error - that is, within a few days. It was not a new defect. What had changed was the way it was used: instead of individual documents, batches were going into the system. The fix in the end was not swapping the technology but changing the scenario - asynchronous batch processing instead of waiting for one document after another.
Those two dates are worth comparing. Almost three months passed between choosing the technology and that failure, which looks like a long time to have checked things in. Four days passed from the real launch - and it is the second interval that decides, because only there did a load appear that had nowhere to come from before.
The lesson for acceptance: a function that passes on one document has not been tested. It has been tested when it passes on as many documents as you will push through it at peak - and at the same rhythm.
What "on your data" means in practice
The sentence "we want to see it on our own data" sounds self-evident, and in practice it turns into an export of ten pretty records. Those prove nothing, because pretty records get through even the worst integration.
An acceptance sample is put together deliberately, and it has four groups in it:
- The worst real records, not average ones. The longest name, a missing company number, diacritics in a field the supplier says should not have them, two addresses for one company, a line item with a discount and a surcharge at the same time.
- History, not just new records. Data entered five years ago has a different structure from data from last week, because somebody else entered it under different habits.
- Peak volume, not an average day. When a hundred and fifty items arrive on one day, then a hundred and fifty items are what gets tested. Not fifteen.
- Concurrency. Two people working at the same moment, the scenario running in the middle of that, and somebody editing the very record being transferred.
The last point is the one most often left out, and its consequences are the hardest to track down, because they do not repeat on command.
Acceptance is a record, not an impression from a demonstration
A demonstration ends with "that looks good", and anything can be justified with that afterwards. An acceptance record replaces it with four columns that can still be read six months later:
Example:
| What was tested | On what data | Result | Who fixes it and by when |
|---|---|---|---|
| Creating a document | 150 items, peak | passed | - |
| Document changed after transfer | 12 records from last year | failed | supplier, 12 Sep |
The record does three things at once. It defines what counts as finished. It separates a defect from extra work, because a defect is what was in the record and did not pass. And it gives both sides a list to tick off instead of an argument about what was promised at a meeting.
One sentence always belongs in the record: what happens when the scenario fails in real use. Who will see it, where it will show up, and how quickly the supplier is on it. Without that, acceptance is signed for a state of affairs that lasts one day.
When acceptance cannot be done, and what to do instead
Sometimes real data cannot be handed to a supplier at all - it is personal, it is under a confidentiality agreement, or releasing it is a risk in itself. In that case acceptance on a demo is not a solution but an emergency, and it can be made smaller in two ways:
- An anonymised sample with the structure preserved. Names are replaced; lengths, formats, spaces and missing values stay. Most integration errors are about structure, not content.
- Acceptance at your place, on your machine, with your person at the keyboard. The supplier watches but does not type. This format also exposes what works technically and is unusable in practice.
Five questions to ask before signing acceptance
They work on anyone including us, and ask for the answers in writing.
- What data was what I just saw running on - mine or yours?
- How many records went through in one run, and how many do you expect at my peak?
- What happens to a half-finished record if the scenario fails in the middle?
- Which of my exceptions have you not seen yet, and what will we do when they turn up?
- Who finds out about an error first - you or us?
A demonstration answers the question of whether it works. Acceptance answers the question of whether it works at your place. Those are two different questions, and the second one is what you pay for.
We described the same logic earlier for connecting an e-shop to accounting, where it ends in the sentence we are unpacking here in full: before you sign it, ask to see it on your data, not on a demo (Shoptet API and connecting to Pohoda).
Send us a sample, not a description
When you ask us for automation, ask for acceptance on your own data and put it in the enquiry. It saves both sides: we find out the scope before we write a price, and you find out whether we have seen that kind of load before.
What we automate and to what extent is on the automation page; connecting to business systems we describe separately under CRM and ERP.
Write to info@lamapixel.com or call +420 775 599 009.
