The demo proved that the model could answer the question. It did not prove that the customer could supply the records in a usable form. For an AI product that depends on business data, the first technical risk often sits between the systems where that data lives.
In 1999, NASA lost contact with the Mars Climate Orbiter as the spacecraft approached Mars. The mission had already travelled from Earth and reached the point where careful navigation mattered most. One part of the ground software produced thruster data in pound-seconds. Another expected newton-seconds.
The mismatch passed through the interface.
Arthur Stephenson chaired the investigation board that examined the loss. NASA’s Mars Climate Orbiter Mishap Investigation Board Phase I Report documented the unit mismatch and the failures around verification, communication and mission operations. The spacecraft was lost because two working parts of a larger system did not agree on the meaning of the data moving between them.
That is a useful shape to remember when an AI demo works with prepared inputs and stalls on customer records.
The model was waiting for data the customer did not have
The Cape Town founder had shown the customer a convincing result. Give the product the relevant account history, invoices and operating notes, and it could produce the analysis the customer wanted.
Then the customer opened their actual systems.
Some account records lived in the CRM. Invoice status sat in the accounting tool. A shared spreadsheet contained corrections that had never made it back into either system. The spreadsheet also carried context known to the operations team: which accounts had changed names, which entries should be ignored, and which late payments reflected a dispute rather than a cash problem.
The founder had designed the product around a clean input. The customer had a distributed record of reality.
This distinction changes the work. A connector can retrieve fields from three systems, but retrieval alone does not settle which record is current, which identifier refers to the same customer, or which source wins when two values conflict. The AI may receive more data while becoming less certain about what that data means.
The Mars Climate Orbiter failure had much higher stakes, but the mechanism maps cleanly. Each component can appear to function while the contract between components remains undefined.
A successful demo can hide the expensive part
Prepared demo data answers a narrow question: can the product produce a useful result when the required information is present and shaped correctly?
A customer deployment asks harder questions. Where does each input originate? Who updates it? How often does it change? What happens when the CRM says an account is active, the accounting tool shows an unpaid invoice, and the spreadsheet says the contract ended last month?
Those questions belong in product discovery, before a founder promises an integration date or hires someone to build three connectors.
I would ask the customer to walk through one complete decision using current records. No exported sample assembled for the meeting. Start with the account they would investigate tomorrow and trace every fact needed to reach an answer. Record the source, owner and exception for each field.
That exercise usually exposes three categories:
- Data the product can read directly and use with little interpretation.
- Data that exists but needs matching, cleaning or an agreed source of truth.
- Data that staff know but have never recorded consistently.
The third category is where confident automation claims tend to become manual operations. A person has been resolving ambiguity from memory, email threads or a spreadsheet note. The AI cannot reproduce that decision until the team makes the rule explicit or accepts human review.
This is the same boundary I watch when deciding whether a workflow can honestly be called autonomous. If someone must reconstruct the customer record before every run, the product has automated the visible analysis while leaving the preparation work untouched.
Test the data contract before building the integration
The next prototype should test the path from source records to decision, not add another polished model response.
Choose a small set of real customer cases. Remove or protect sensitive information as required, then run each case from the systems where staff actually maintain it. Write down every manual correction. When two systems disagree, require the customer to name the rule for resolving the conflict.
This creates a data contract in plain language:
The CRM owns the account identifier. The accounting tool owns payment status. The spreadsheet may add notes, but it cannot silently replace either value. Unmatched records stop for review. Missing fields produce a visible warning rather than a confident answer.
The exact rules will differ. The point is to make them testable.
This also changes the commercial conversation. The founder can separate the product’s core value from the customer’s data work. Perhaps the first deployment supports one accounting tool and a reviewed spreadsheet import. Perhaps the customer must clean identifiers before onboarding. Perhaps the product is still worth buying with a person approving uncertain matches.
Each version can be evaluated honestly. “We integrate with your stack” cannot.
Ship the smallest path that survives real records
Arthur Stephenson’s board did more than identify a conversion error. Its report examined the conditions that allowed incompatible assumptions to travel through a mission without being caught.
A founder should apply the same discipline before treating a demo as deployment evidence. The important test sits at the boundary: what does this field mean, which system owns it, and what happens when the inputs disagree?
For the Cape Town founder, the next useful milestone is one customer decision completed from the CRM, accounting tool and shared spreadsheet without hidden cleanup. Mark every exception. Keep human approval where the rule remains unresolved.
Only then does the product know what it is being asked to automate.
Comments
No comments yet.