The contract would have extended our runway, but accepting it would have put a client’s custom AI system ahead of the product we had already chosen to build. I turned it down because the cash solved an immediate problem by creating a larger strategic one.
At 4:18 on Tuesday afternoon, Kofi, a composite founder based on decisions I have faced across Ghana, Germany and the US, was staring at the unsigned contract on his laptop in Accra. His coffee had gone cold. The prospective client wanted an answer before close of business.
The project was larger than anything else in the pipeline. It also required most of his small team for several months, a separate architecture, and integrations that no other customer had requested.
If he declined, payroll would keep eating into a runway that already felt too short. If he accepted, the product roadmap pinned beside his desk would become fiction.
The contract was buying more than our time
Large contracts rarely announce themselves as strategy decisions. They arrive as revenue.
That framing makes them difficult to refuse. When runway is tight, money in the bank looks concrete while product focus feels theoretical. Salaries, software bills and contractor invoices have dates attached. The cost of distraction usually appears later.
Kofi opened the delivery plan again. The first milestone alone would pull the lead engineer away from the core product. The second required a workflow designed around one client’s internal process. By the final milestone, the team would know a great deal about building this customer’s system and less about whether their own product deserved to exist.
The contract could fund the company for longer. It could also leave the company alive, busy and pointed in the wrong direction.
I have learned to ask a blunt question at this stage: if the client disappeared after delivery, what would remain?
In this case, the answer was thin. Some infrastructure might be reusable. The deeper value would sit in custom permissions, custom integrations and operating rules specific to one buyer. The team would earn revenue, but the product would gain little evidence.
That distinction matters when you have five people and one runway. A custom build does not sit beside the roadmap. It competes with it.
A good customer can still be the wrong product decision
The prospective client had a real problem. They understood the value of solving it and were prepared to pay. Those are strong signals for a services business.
They are incomplete signals for a product company.
A product needs repeated demand, some consistency in how the problem appears, and an approach that can serve the next buyer without rebuilding the system. One credible request can prove urgency. It cannot prove repetition.
This is the same tension behind what happens when a pilot requires an architecture your product does not support. The danger begins when a founder treats commercial interest as evidence that every requested implementation belongs in the product.
At 4:31, Kofi wrote three columns on a sheet of paper: cash gained, learning gained, and product time lost.
The first column was compelling. The second depended heavily on assumptions. The third included the next release, two customer interviews and a pilot the team had spent weeks preparing.
For one uncomfortable minute, declining still looked reckless. There was no replacement contract waiting. The next fundraising conversation might go badly. A delayed sale could force Kofi to reduce the team.
The bad ending was clear: protect the roadmap, run short of cash, and discover too late that the custom project had been the safer choice.
The decision needed a boundary, not a forecast
No spreadsheet could tell Kofi which future would happen. He needed a rule for deciding under uncertainty.
The useful boundary was simple: the company could accept work that funded the product, tested a product assumption, or produced a reusable capability. This contract did not meet enough of those conditions. Its largest benefit was time, measured as runway. Its largest cost was also time, measured as months the team would not spend testing its main bet.
At 4:46, Kofi sent a short response. He thanked the client, explained that the requested build sat outside the company’s product direction, and left the door open for a smaller discovery engagement if the scope changed.
Then he closed the forecast.
The contract remained unsigned. The runway remained uncomfortable. Nothing about the decision felt triumphant.
That matters. Founders sometimes expect the correct decision to produce immediate relief. In practice, a strategic boundary often makes the short term harder. You carry the doubt because the alternative would quietly turn one company into another.
The choice resembles Kojo’s two credible requests competing for one runway. Both opportunities may be real. The team still has to decide which company it is building.
What stayed on the roadmap
The next morning, Kofi returned to the release plan taped beside his desk. The lead engineer was still assigned to the product. The customer interviews were still scheduled. The pilot still had a chance to answer the question the company had chosen to pursue.
He added one line at the top of the pipeline review document: “What remains valuable after this contract ends?”
That question will not make a large deal easier to decline. It will make the hidden purchase clearer. A client offering runway may also be asking for your roadmap, your engineering attention and the next several months of product learning.
Before the next proposal reaches close of business, write down what the money funds, what the work teaches, and what your team must stop doing to deliver it. Then decide which cost your company can survive.
Comments
No comments yet.