The strongest model can still be the wrong product if the buyer cannot accept where its data is processed. On that Friday call with a Berlin team, one question changed my priority from defending model quality to redesigning the AI feature’s deployment: “Where does the code run?”
In 2012, Knight Capital Group faced a different deployment question. The firm had updated software across its trading system, but one of eight servers did not receive the new code. When trading opened in New York on August 1, the missed server activated obsolete functionality. Knight Capital lost more than $460 million in about 45 minutes.
The US Securities and Exchange Commission documented the failure in its 2013 enforcement action against Knight Capital. The code itself was only part of the incident. The deployment process, the inconsistent server state and the absence of adequate controls turned a software release into a threat to the company’s survival.
The question behind the model question
I entered the Berlin call prepared for the AI discussion founders usually expect.
How accurate is the output? Which model performs better? How quickly does the feature respond? Where does it fail? Those questions matter, especially when a small team has limited runway and each week spent rebuilding one component delays something else.
The Berlin team moved below that layer.
They wanted to know where the code executed, where their data travelled and which outside services touched it. A technically impressive answer about model quality could not settle those concerns. The architecture had become part of the buying decision.
That changed the shape of the work. Improving prompts would not answer a deployment question. Running another model comparison would produce better evaluation results while leaving the commercial objection untouched. The feature needed a deployment design the customer could examine and accept.
For founders selling across Ghana, Germany and the US, this distinction arrives earlier than expected. A demo can work from Accra and still encounter a different standard of scrutiny in Berlin. The issue may appear during procurement, a security review or the first serious technical call. By then, “we use a reputable provider” is too vague.
Deployment is part of the product
Small AI teams often treat infrastructure as an implementation detail to decide after users confirm demand. That approach can preserve runway during early testing. It can also create expensive rework when the first serious buyer has residency, access or audit requirements that the original architecture cannot meet.
The practical question is not whether every early-stage company should build its own model or host everything itself. Most should not. The better question is which deployment decisions remain reversible.
If the application sends every request directly to one external model provider, changing providers later may touch authentication, logging, evaluation, error handling and product behavior. If customer data is mixed into logs without a clear retention rule, fixing the problem involves more than changing a server location. If the team cannot trace which service handled a request, it cannot give a precise answer when a buyer asks.
This is where the Knight Capital analogy matters. One server running the wrong code was enough to expose the weakness of the whole release process. For an AI product, one hidden data path or one environment configured differently can invalidate the confident architecture diagram shown to a customer.
Design for the answer you may need to give
Before the next buyer call, draw the request path as it exists today.
Start when a user submits data. Mark each system that receives it, each location where it may be stored, every model endpoint involved and every log that could preserve part of the request. Include development and staging systems. Those are easy to omit because the customer does not see them, yet they still shape the honest answer.
Then separate facts from assumptions. “The provider supports regional deployment” does not prove your account uses it. “We do not need to store prompts” does not prove a logging tool has not retained them. Check the actual configuration.
Finally, decide which parts need an abstraction boundary. A model gateway, a configurable storage layer or separate deployment profiles may add work now. The value comes from preserving choices: changing a provider, keeping one customer’s processing within an agreed region or disabling a logging path without rebuilding the feature.
The same discipline applies to product decisions beyond infrastructure. Daniel’s $699 test shows why a founder should test the decision that could kill the idea before spending runway polishing the rest. Deployment deserves that treatment when it can block the sale.
Put the architecture in the sales conversation
After Berlin, the useful artifact was no longer another benchmark table. It was a deployment answer that could survive follow-up questions.
Founders should bring that answer into customer discovery sooner. Ask prospective buyers what they need to know about processing location, storage, outside providers and access before they can approve a pilot. Their replies may reveal that a hosted API is acceptable. They may also reveal a requirement that changes the product’s architecture.
Do not promise a deployment model before verifying it. Write down what runs where, confirm the configuration and identify the remaining gap. Then price the gap against the opportunity and the runway it will consume.
Knight Capital’s missed server showed how dangerous the distance can become between the system a team believes it deployed and the system actually running. Before the next Friday call, trace one real request from the customer’s screen to the model and back. That path is part of the product you are selling.
Comments
No comments yet.