A reliable AI demo must survive the failure of every dependency the team chooses to own, including connectivity. If a customer cannot complete the core task when the internet drops, backup power alone does not make the product ready.
In April 1970, Apollo 13’s crew had enough oxygen to breathe, but carbon dioxide was building inside the lunar module. The command module’s square lithium hydroxide canisters could remove it. The lunar module used round openings.
NASA engineers in Houston had to make incompatible parts work with materials already aboard the spacecraft. Flight controller Ed Smylie’s team developed a procedure using items available to the crew, including plastic bags, cardboard and tape. NASA’s account of the mission documents the improvised adapter that helped keep Jim Lovell, Jack Swigert and Fred Haise alive until their return.
The power supply mattered. So did the connection between two parts nobody expected to use together.
The failure hiding behind the generator
Now put that problem inside a Tuesday customer pilot in Accra.
A founder arrives with a charged laptop, a tested generator and an AI workflow that behaved properly the night before. The prospective customer has brought the people who will use it. Someone uploads the first document. The interface waits.
The internet connection has failed.
The generator continues running. Every visible precaution appears to be in place, yet the product cannot reach the model, retrieve a record or return an answer. The team can explain the outage, switch networks and ask for patience. None of those actions lets the customer finish the job they came to test.
This is where founders often misclassify the problem. They call it an internet failure because the internet failed. The customer experiences a product failure because the product stopped.
That distinction changes the next decision. The team can polish the interface before the next pilot, or it can decide which part of the workflow must remain useful during a connectivity interruption. With limited runway, it probably cannot do both.
Reliability begins with the customer’s task
The useful question is not, “Can we make the entire AI product work offline?” That scope can swallow months.
Ask instead: “What must the customer still be able to do?”
Perhaps the user needs to upload documents and preserve them locally for later processing. Perhaps the product can display the last verified record while clearly showing that fresh analysis is unavailable. Perhaps the workflow needs a manual fallback that captures the decision, its owner and the evidence used.
Each option carries a different cost. Local queues create reconciliation work. Cached information needs visible timestamps. A manual fallback can become a permanent operational burden if the team quietly relies on it instead of fixing the product.
The decision should follow the customer’s job and the consequence of delay. If the demo supports a sales conversation, waiting may be acceptable. If it supports a time-sensitive approval, the same outage may stop the business process entirely.
That is why reliability belongs in product scope. It determines what the product promises when conditions are ordinary, and what it admits when they are not.
This resembles another product decision I have seen repeatedly: a team has several working capabilities but only enough time to prove one. The hard part is choosing the failure that matters before the market chooses it for you. Kelechi’s three-feature decision follows that constraint from a different direction.
Draw the boundary before the next pilot
After a failed pilot, the temptation is to add backups everywhere. A second router. Another provider. A local model. More retries. More monitoring.
Some of those may be sensible. Together, they can become an expensive attempt to hide an undefined promise.
Start with the pilot path. Write down every external dependency between the customer’s first action and the result: electricity, internet access, authentication, model provider, database and any third-party service. Then mark what the user sees when each one fails.
A spinner is not a failure state. Neither is a console error the customer never sees.
For the next pilot, choose one degraded path that protects the core task. Make queued work visible. State which data is stored locally. Show when the system will retry. Give the operator a clear way to stop duplicate submissions. If a human must take over, record where that handoff begins.
Then test the failure deliberately. Disconnect the network during the exact workflow the customer will run. Restore it and check whether the product resumes safely, repeats work or loses context. The point is to observe the boundary while the team can still change it.
This is close to the approval problem in AI agent code changes: automation becomes trustworthy when the team defines what can proceed, what must pause and who owns the exception.
Own the promise, not every dependency
A small team cannot control Ghana’s connectivity, a cloud provider’s availability or a customer’s network. It can control the promise it makes around those conditions.
That promise may be modest: the product will preserve the customer’s work, explain what is unavailable and resume without creating duplicate actions. For an early pilot, that can be more credible than claiming uninterrupted AI performance.
Apollo 13 did not gain a perfectly redesigned life-support system in flight. Smylie’s team solved the specific interface failure threatening the crew with the materials already available.
Before the next Tuesday pilot, unplug the internet yourself. Watch where the customer’s task stops. That stopping point is the reliability decision your company owns.
Comments
No comments yet.