The founder should pause the signature and turn the private-deployment clause into a product decision with its own price, scope and acceptance test. A pilot that requires an architecture the product does not support can consume the roadmap while still being described as a small contract.
On 23 September 1999, NASA’s Mars Climate Orbiter passed behind Mars and stopped communicating with Earth. The team at the Jet Propulsion Laboratory in Pasadena waited for the signal to return. It did not.
The spacecraft had reached Mars after a journey of roughly nine months. The failure investigation later found that one part of the ground software produced data in English units while another expected metric units. That mismatch affected the spacecraft’s trajectory. NASA’s Mars Climate Orbiter Mishap Investigation Board documented the failure in its Phase I report.
The individual systems had done what their teams expected. The mission failed at the boundary between those expectations.
One clause can redraw the whole product
The private-deployment requirement does the same kind of damage when it appears hours before signing.
Until that point, the founder may believe the overseas pilot means configuring an existing product, supporting a customer through onboarding and learning from real use. The clause reveals a different project. The customer expects the product to run inside infrastructure they control, under security and operational conditions the startup never designed for.
That change reaches further than hosting.
Who applies updates? Who monitors failures? Can the product call external AI services? Where are logs stored? How will support reproduce a problem when the founder cannot access the environment? What happens when the customer’s network blocks a dependency the product assumes is available?
A private deployment can also split the product into two versions. The hosted version keeps changing. The customer installation stays pinned until someone prepares, tests and coordinates an update. A founder with a small engineering team now owns release management for an environment the team cannot fully see.
The contract may still call this a pilot. The engineering work says otherwise.
Price the architecture before pricing the pilot
The first useful response is neither an immediate refusal nor a hopeful signature. It is a short technical and commercial pause.
Translate the clause into work before negotiating the fee. Write down the deployment model, external dependencies, identity requirements, update process, logging access, support boundaries and exit plan. Mark every assumption that still depends on the customer’s answer.
Then separate three costs.
The first is build cost: the engineering required to make the product deployable outside its current environment.
The second is ongoing cost: maintaining releases, diagnosing incidents and supporting infrastructure differences after the pilot begins.
The third is roadmap cost: what the team will delay while building for one customer.
That third number rarely appears in the proposal, but it may be the largest. A contract can fund several months of work while quietly moving the company away from the product its next ten customers need. I would test that risk with the same discipline described in The Spreadsheet That Revealed Who Really Owns Your Roadmap.
The founder now has three honest options: narrow the pilot to the existing hosted product, price private deployment as a separate project, or walk away. Each option is clearer than burying architectural work inside a pilot fee.
Rewrite the clause around evidence
If the customer genuinely requires private deployment, the contract needs an acceptance test that reflects the new reality.
“Successfully deployed” leaves too much open. Success should identify the environment the customer provides, the integrations included, the data available for testing, the person responsible for access and the evidence that marks completion. Support obligations should say what the startup can inspect and what remains with the customer.
The pilot should also answer a product question. Will this deployment prove demand in a repeatable market, or only prove that the team can satisfy one buyer’s infrastructure policy?
That distinction matters for founders selling from Accra, Lagos or Johannesburg into organisations in Europe or the US. The overseas contract can look large relative to current revenue. The requested exception can look temporary. Currency and prestige do not reduce the engineering burden.
A narrower scope can keep the relationship alive. AI Security Questionnaires: Why Kojo Narrowed the Pilot to Keep the Contract Alive examines the same underlying move: reduce uncertainty before promising more product than the contract has paid for.
Treat late requirements as operational signals
The timing of the clause is evidence.
If a fundamental deployment condition appears only on Friday, other assumptions may still be hidden in procurement documents, security reviews or conversations between the buyer’s technical and commercial teams. The founder should ask for one joint review before signing, with every person who can reject the deployment represented.
Mars Climate Orbiter was lost because two parts of one mission handled the same data differently. The relevant lesson for a founder is plain: agreement at the headline level does not protect the boundary between systems.
Open the architecture diagram. Trace every dependency the private environment changes. Put each unresolved assumption beside the contract clause it affects. Then send the revised scope before anyone signs.
Comments
No comments yet.