A pilot contract can extend runway, but only when the work leaves the product stronger after the contract ends. If the buyer requires a rebuild that serves no other credible customer, the contract may buy six weeks while quietly consuming the company.
At 4:38 on Friday afternoon, Kwame sat in a small office in Accra with the contract open on his laptop and a paper cup of coffee going cold beside it. He is a composite founder, but the decision is familiar: six weeks of runway, three people on payroll, and an overseas buyer offering enough money to keep the company alive for several more months.
The condition sat halfway down the implementation schedule. Work would begin Monday. The team would rebuild the product around the buyer’s internal process before the pilot could launch.
If Kwame declined, payroll might become impossible before another serious conversation reached procurement. If he signed, his team would stop building the product they had spent the past year validating.
He had the weekend to decide which risk could still produce a company.
The contract price hid the product cost
The pilot looked profitable in a spreadsheet. The first payment covered salaries, cloud costs and the overdue invoice from a contractor in Berlin. That calculation answered the immediate cash question.
It missed the product question.
The buyer wanted the same outcome Kwame’s product promised, but through a different architecture. Their data would arrive differently. Their approval process required new roles. Their reporting format reflected an internal workflow that none of Kwame’s other prospects had mentioned.
The team could build it. That was part of the danger.
Technical feasibility often makes a bad product decision feel responsible. Engineers can estimate the work, founders can map the milestones, and everyone can start Monday. Six weeks later, the company may have a functioning pilot and two products occupying the same codebase.
This is the tension behind what happens when a pilot requires an architecture your product does not support. A customer request can be commercially credible and strategically expensive at the same time.
Kwame needed to calculate the contract in a different unit: what would the company be unable to learn while the team completed the rebuild?
Separate reusable work from buyer-specific work
On Saturday morning, Kwame rewrote the implementation plan in three columns.
The first held work already on the roadmap. The second held changes that could serve other customers if the pilot succeeded. The third held requirements that existed only because of this buyer’s internal setup.
The third column was longer than he expected.
That did not automatically kill the contract. Early-stage companies often survive because a customer pays for capabilities before the broader market is ready to fund them. The useful distinction is whether the custom work creates a reusable advantage or a permanent obligation.
A new permissions model might support future customers with similar approval needs. A one-off reporting format could become maintenance work with no wider demand. A manual import process might be acceptable during a pilot if both sides agree that it will remain temporary.
The contract needed to reflect those differences.
By Sunday afternoon, Kwame had reduced the Monday rebuild to a smaller integration layer. The core product would remain intact. Buyer-specific reporting would stay outside the main product until another customer asked for something similar. The pilot would test the commercial assumption before the team committed to the full architecture.
The buyer could reject those terms. That possibility remained live, and with it the chance that Kwame would enter his final six weeks without the payment.
Negotiate the learning before the scope
Founders under runway pressure often negotiate price, payment timing and delivery dates first. Those terms matter, but they do not protect the product on their own.
Kwame also needed access to the people whose behaviour would determine whether the pilot worked. He asked for scheduled conversations with the operational team, agreed success criteria before development began, and defined which requests would require a separate scope decision.
Those terms changed the pilot from outsourced development into a test.
They also gave him an exit condition. If the buyer would fund the rebuild but prevent access to the people using it, the company would collect implementation feedback without learning whether the product solved a repeatable problem.
That distinction matters when cash is short. Revenue can extend the calendar while leaving the central uncertainty untouched.
The same issue appears when funding conditions force you to build a different product. Money comes with direction. The founder’s job is to identify that direction before accepting it.
Monday should start with a boundary
At 8:12 on Monday morning, Kwame joined the buyer’s call with a revised scope. His team would begin after both sides agreed on three boundaries: the core product would remain unchanged, buyer-specific work would stay isolated, and the pilot would measure a defined customer behaviour.
The buyer pushed back on the reporting requirement. For several minutes, the contract looked likely to disappear.
Then they accepted a manual report for the pilot period, with the larger rebuild dependent on evidence from actual use.
Kwame still had a difficult delivery ahead. The contract had not removed the company’s risk, and the pilot could still fail. What changed was the shape of the bet. His team would spend Monday testing whether the overseas demand belonged on their roadmap, instead of assuming a large cheque had already answered that question.
Before signing a runway-saving pilot, mark every requirement that serves only one buyer. Move those items outside the core product, attach them to a learning goal, or price them as the separate business they may become.
Comments
No comments yet.