When two credible buyers want different versions of the same product, choose the version that tests the most important assumption before runway forces the decision for you. Buyer enthusiasm matters, but the stronger signal is the commitment that produces reusable evidence without splitting the product in two.
At 10:20 on Tuesday, I imagined a founder called Nii standing beside a whiteboard in Accra, phone still warm from a call with Lagos. His coffee had gone cold. The buyer wanted his AI copilot embedded inside an existing operations dashboard, where staff could use it without changing tools.
By 3:00, a Berlin buyer had made the opposite request. Give the copilot its own interface, keep it separate from existing systems, and let one team test it quickly. Both buyers understood the problem. Both could describe where the product would sit. Nii had enough cash to build one version before payroll became uncertain.
Two credible buyers can still provide weak evidence
The Lagos request sounded commercially serious. Embedding the copilot could place it inside a workflow people already used, which might improve adoption. It also required work around the buyer’s existing product, permissions and data structure. A successful deployment might prove that Nii’s team could serve that buyer. It might say little about whether the underlying product worked elsewhere.
The Berlin request looked smaller. A standalone version would expose the product directly. The team could watch where people hesitated, which answers they trusted and whether they returned without being reminded. Those observations could shape a product sold to another buyer.
That distinction matters when runway is short. Revenue from custom work can extend the company’s life while quietly replacing the company’s product with a series of client projects. I explored the same tension in Pilot Contracts: How Kwame Protected the Core Product While Extending Runway.
Nii could feel the deadline closing. If he chose Lagos and the integration expanded, Berlin could walk away before seeing anything. If he chose Berlin and the standalone test produced no repeated use, he would have spent his remaining build window disproving the cleaner product story. There was no safe option hiding between them.
Compare what each build teaches
I would put both requests into the same three columns: cash received before development, time until observable use, and value of the evidence outside that account.
The first column separates interest from commitment. A detailed call, a senior buyer and an enthusiastic follow-up can still end with no contract. A deposit, paid discovery phase or signed pilot with a clear start date changes the decision because the buyer now carries part of the risk.
The second column asks when reality enters the room. An embedded build can absorb weeks before a user touches the copilot. A standalone version might reach a small team earlier, although distribution then becomes Nii’s responsibility. The relevant milestone is observable behaviour, not completed code.
The third column protects the product from becoming unrecognisable. If Nii builds a permission layer for one buyer’s internal setup, can the next customer use it? If he changes the copilot’s interface after watching five people struggle with the same step, that learning has a better chance of travelling.
This is where larger opportunities can distort judgment. The bigger cheque receives more attention even when the evidence behind it remains thin. The Empty Evidence Column, and What a Larger Cheque Could Cost You examines that problem directly.
Make the buyer pay for the fork
At 6:40 that evening, Nii returned to the whiteboard. He had written “embedded” on one side and “standalone” on the other, then filled the space beneath both with tasks. The embedded list kept growing.
The turn came when he stopped comparing requested features and compared buyer commitments. In this composite scenario, the Berlin team would fund a tightly scoped pilot and place named operators into scheduled testing sessions. The Lagos buyer wanted an estimate before discussing payment or access to the people who would use the copilot.
Nii chose the standalone pilot. He did not conclude that standalone was the permanent product. He bought a faster answer to the current question: would operators use the copilot to complete real work when the product had to earn its place on its own?
He kept the Lagos conversation open with a condition. An embedded version required a paid discovery phase that would map the integration, identify the first user group and define which parts could become reusable product work. If the buyer would not fund that learning, Nii’s runway would not fund it on their behalf.
Leave the next decision visible
The morning after the choice, the whiteboard still held both versions. Nii circled the standalone build and wrote three conditions beneath it: paid commitment, named testers and a date for observing first use.
That did not settle the company’s architecture or market. It made the next decision cheaper. If the pilot showed repeated use, Nii would have behaviour to guide the product. If it failed, he would learn before building an integration around a weak core. If Lagos funded discovery, he could examine the embedded route without pretending a sales conversation had already validated it.
When two buyers pull the roadmap apart, ask each one to reduce a different uncertainty with money, access or behaviour. Then build the version whose evidence can survive the buyer who requested it.
Comments
No comments yet.