An AI demo that depends on perfect Wi-Fi is demonstrating a lab condition, not a customer outcome. Before the first customer session, test the complete task under interrupted connectivity and decide exactly what the product should do when the connection drops.
Consider Lwazi, an illustrative composite of a Cape Town founder. At 10:17 on a Thursday morning, he sat beside a prospective customer with his laptop open and a paper cup cooling near the trackpad. His AI feature had completed the same document task throughout the week. Then the connection flickered.
The progress indicator stopped. Lwazi refreshed once, then again. Across the table, the customer folded her arms and waited.
If the task failed now, the pilot would probably end in that room.
The office proved the model, not the product
Lwazi’s team had tested the feature carefully. They had tried short documents, long documents and awkward inputs. They had corrected prompts, reduced hallucinations and checked the final output against work completed by hand.
Every test happened in the same office, on the same stable connection.
That detail felt incidental until the customer session. The model could complete the task. The product could not reliably carry the user from upload to result when the network changed halfway through.
This distinction matters for AI products because a single visible action often hides several remote steps. A file uploads. A service extracts its contents. A model receives a request. Another service stores the answer. If the connection disappears between those steps, the user sees one frozen screen and has no idea which part failed.
Lwazi knew the system might still be processing. He also knew that saying, “It is probably still running,” would make the silence worse.
Failure needs a designed response
The connection returned briefly. The page reloaded, but the task had no visible result. Lwazi now faced three possibilities: start again and risk creating a duplicate, wait for a process he could not confirm, or move on without showing the feature that had earned the meeting.
The real product decision arrived there.
What should the user see after an interruption? Should the upload resume? Should the task remain queued? Can the system show the last confirmed step? If the user retries, can the backend recognise the original request and prevent duplicate work?
These questions belong in the product plan before anyone polishes the demo animation. They determine whether a customer trusts the system when conditions become ordinary.
I would start by forcing the connection to fail at each important step. Switch it off during upload. Interrupt it after submission. Restore it while processing continues. Retry the same action twice. Then record what the user sees, what the server receives and whether the work can be recovered.
The expected behaviour should be written in plain language: “Your file finished uploading. Processing will continue when the connection returns.” Or: “This task did not start. Retry when you are connected.” Silence leaves the customer to invent a worse explanation.
This is the same ownership problem that appears when a feature keeps creating work after release. Support debt can reveal who truly owns the product after launch. Connectivity failures simply expose that debt earlier.
The honest fallback saved the session
With the customer still waiting, Lwazi stopped refreshing. He said the connection had interrupted the live run, explained that the current build could not confirm whether the task had completed, and opened a previously generated example.
That fallback did not prove reliability. It did something more useful in the moment: it kept him from pretending.
The customer could now judge the output while Lwazi documented the failure honestly. The pilot remained uncertain. She wanted the feature tested again under the conditions her team actually worked in, and Lwazi left with a requirement he had missed.
Back at the office, the team changed the next sprint. Retry protection moved ahead of a new output format. They added visible task states, stored progress outside the browser session and prepared a local example for future demonstrations. They also wrote down which parts still required a live connection.
A prepared fallback should never disguise a broken path. It should preserve the conversation when the environment prevents a fair test. The same principle applies when an external service may miss a customer commitment: state what the dependency changes before the deadline decides for you.
Test where confidence can break
Before the next customer meeting, Lwazi returned to the same conference table. This time, he deliberately interrupted the connection during processing.
The screen showed the last confirmed state. When connectivity returned, the task continued without a second submission. He still carried the saved example, but he did not need to open it.
That is the test I would run before calling an AI feature ready for customers: break the network at the least convenient moment and watch what the user has to guess. Every guess is a product decision the team has postponed.
Comments
No comments yet.