An AI feature is ready when it works on the device your paying customer uses, under the conditions they use it in. A successful demo on the founder’s newest phone proves far less than a failed test on an older handset.
At 4:40 on a Thursday afternoon in Cape Town, Sibusiso held two phones above the small desk he worked from: his new handset in his right hand, an older Android phone in his left. Sibusiso is a composite founder, but the decision in front of him is one I recognise from shipping products on limited runway.
His AI feature read a photograph of a handwritten stock sheet and turned it into editable inventory entries. On his phone, the photograph uploaded, the model returned a clean result, and the screen remained responsive. He had already recorded the demo for a prospective customer.
Then he tried the phone his first paying customer actually used.
The upload spinner stopped. The screen went blank. When he reopened the app, the photograph and the customer’s edits were gone.
The device changed the product decision
Sibusiso had promised to show the feature to the customer the next morning. If it failed again, he risked losing the first account that had agreed to pay for it. That account mattered more than the demo recording, the planned launch post, or the encouraging reactions from friends who had tested on newer phones.
He could still present the polished recording and call the live failure an edge case. He could also postpone the demonstration, spend the night rebuilding the image flow, and arrive with no guarantee that the fix would hold.
Neither option felt safe.
The first hid the condition most relevant to the buyer. The second could turn one device problem into an uncontrolled rewrite hours before a customer meeting.
This is where founders often treat technical success as a binary state. The model returned the correct answer, so the AI worked. But the customer never reached that answer. For her, the product failed before the intelligence inside it had a chance to matter.
A model can be accurate while the feature remains unusable. Memory pressure, image size, browser behaviour, network interruptions, and lost state can decide whether the customer experiences any of that accuracy.
He reduced the promise before expanding the code
With the meeting close, Sibusiso made a smaller call. He stopped trying to preserve the full experience.
He reduced the image before upload, added a visible retry action, and kept the photograph available when the request failed. He also removed the automatic jump to the results screen. The customer would now see what was happening and decide when to try again.
The feature became less impressive in the recording. It also became easier to recover when something went wrong.
That trade matters. A founder with limited runway rarely has time to make every device behave identically. The useful question is which failure must become survivable before the next customer sees the product.
I have made the opposite mistake while building products. I have spent too long improving the successful path because that was the path I could reproduce on my own equipment. The screens looked better. The response felt quicker. Meanwhile, the real risk sat one device generation behind mine, waiting inside a condition I had never tested.
This resembles the lesson in what a Wi-Fi drop taught Lwazi about recovery. Connectivity and hardware limitations expose the same uncomfortable fact: recovery is part of the product experience.
Test the customer’s constraint before the model’s ceiling
The next morning, Sibusiso placed the older phone on the table and used it for the demonstration. The first upload stalled again.
For a few seconds, the customer watched the spinner. The meeting could still end with the feature dismissed as something that worked only in a founder’s video.
Then the retry control appeared. The photograph remained on screen. Sibusiso tried once more, and the inventory entries loaded without asking the customer to retake the image or repeat her edits.
That second attempt did not prove universal reliability. It proved something narrower and more valuable: the product could fail on the customer’s device without forcing her back to the beginning.
Before your next AI demo, borrow or buy access to the oldest device that matters to the deal. Use the customer’s likely browser. Interrupt the upload. Lock the screen midway. Submit an image larger than the neat sample in your test folder. Then watch what disappears.
Do this before tuning the prompt for another small accuracy gain. The first constraint may sit outside the model entirely.
The older phone belongs in the roadmap
After the meeting, Sibusiso kept both phones on his desk. The newer one remained useful for development. The older one became the final check before customer demonstrations.
That changed how he defined done. A correct model response was one checkpoint. Preserved customer work, visible progress, and a recoverable failure were checkpoints too.
This does not require supporting every handset still in circulation. It requires choosing device boundaries from customer reality instead of founder convenience. Record the devices involved in active deals. Test the weakest relevant one before committing to a date. If the experience cannot recover there, narrow the promise while you still control the conversation.
On Friday afternoon, the older phone was still slow. It no longer erased the customer’s work.
Comments
No comments yet.