A large pilot can extend runway, but accepting it only makes sense when the buyer’s request strengthens a product direction you would pursue without them. Before Friday changes, separate reusable learning from custom work, price the diversion honestly, and set a decision point where either side can stop.
At 4:47 p.m. in Accra, Kojo’s phone lit up beside a half-finished cup of coffee. Kojo is a composite founder: six people, an AI workflow product, and enough cash to reach the end of the quarter if sales arrived soon. The email offered a paid pilot large enough to fund several more months. One condition sat halfway down the page: his team would reshape the product around the buyer’s approval process.
He read the sentence twice. The buyer wanted an answer before Monday.
What the buyer was actually purchasing
Kojo’s product helped small operations teams review customer requests, flag missing information, and prepare the next action. The enterprise prospect wanted a different centre of gravity. Its managers needed extra approval stages, private deployment, and reports designed around internal roles that no other prospect had mentioned.
Every request sounded defensible on its own. Together, they would consume the next product cycle.
The offer created a clean financial answer and a difficult product answer. Saying no could mean cutting a contractor, delaying a planned hire, and returning to fundraising earlier than Kojo wanted. Saying yes could turn his product team into the buyer’s internal software team while the company still carried the risk.
That was the bad ending on the table: the pilot could succeed, the invoice could clear, and Kojo could emerge three months later with more cash but less of a company.
I have seen founders treat this choice as a contest between purity and survival. That framing hides the useful question. What exactly will remain after the contract ends?
A pilot can leave behind tested infrastructure, clearer customer language, a repeatable sales motion, or evidence that a painful workflow deserves a product. It can also leave behind one client’s permissions table and a roadmap nobody else recognises.
The Friday test for custom work
By Friday morning, Kojo had stopped debating the size of the offer. He opened a blank document and divided the requested work into three groups.
The first group covered capabilities already implied by the product: stronger audit records, configurable approvals, and clearer failure handling. Other buyers could plausibly need those.
The second covered uncertain ideas worth testing, provided the pilot produced observable evidence. Kojo could build the smallest version, watch how the buyer used it, and decide what deserved a permanent place.
The third group contained work that existed because this company had organised itself in a particular way. Bespoke reports, internal naming conventions, and approval paths with no obvious use elsewhere belonged there.
The contract became less attractive once the third group had an owner, a delivery estimate, and an opportunity cost. Those requests would delay work his existing prospects had already asked about. The money bought runway, but part of that runway would be spent travelling sideways.
This is the same tension behind Kojo’s private deployment dilemma. A technically possible request can still consume the product direction that made the company worth funding.
Turn the pilot into a bounded decision
At 2:18 p.m., with the response window closing, Kojo rewrote the proposal.
He kept the paid pilot but reduced its scope to one workflow and one team. The reusable capabilities stayed. The buyer-specific reporting moved into a separately priced workstream. Both sides would review named evidence before expanding: completion rates, manual rescues, approval delays, and which exceptions still required a person.
He also added a stopping point.
If the pilot showed that the workflow only worked through constant manual intervention, the team would close it without promising a wider rollout. If the results supported broader use, they would discuss the next phase with new scope and pricing. The buyer could reject those terms. Kojo might still face the contractor call on Monday.
For several minutes, the revised email sat unsent.
Then he sent it.
The important turn was not whether the prospect immediately agreed. Kojo had changed the offer from an open-ended promise into a test with boundaries. He could now learn from the buyer without quietly handing over the roadmap. That distinction matters in AI products, where an impressive demo can conceal the amount of human rescue required. I explored that problem in Can We Call a Workflow Autonomous If a Person Must Rescue It?.
The document to write before Monday
When an offer can change your runway, enthusiasm makes every requirement look strategic. Put the decision into writing before negotiating the details.
Name the product thesis the pilot will test. Mark which work can serve another customer. Price custom delivery separately. State what existing commitment will move if the team accepts. Define the evidence required for expansion, then include the point where both sides can stop.
On Monday morning, Kojo still had an unresolved sale. He also had a proposal his six-person team could deliver without pretending one enterprise buyer represented the whole market. The coffee beside his laptop had gone cold again, but the roadmap on the screen still belonged to them.
Comments
No comments yet.