A pilot buys twelve months when it creates enough cash to keep the company alive without quietly becoming the company’s new roadmap. Before signing, the founder has to decide which parts of the work can become a repeatable product, which remain customer-specific, and what the team will refuse to build.
In 1980, Bill Gates faced a version of that decision in Bellevue, Washington. IBM wanted an operating system for its planned personal computer. Microsoft sold programming languages. It did not own the operating system IBM needed.
The opportunity could have ended there.
Instead, Microsoft arranged to acquire 86-DOS from Seattle Computer Products, adapted the system for IBM, and licensed it while retaining the ability to license the software elsewhere. The Computer History Museum documents the IBM PC’s development and Microsoft’s role in supplying the operating system.
That contract gave Microsoft more than revenue. It changed the centre of the business.
The contract contains a second company
The founder looking at an enterprise pilot on Monday morning usually sees the immediate arithmetic first.
The contract covers salaries. It reduces the pressure to raise. It gives the company a recognised customer and a credible answer when the next prospect asks who already uses the product.
Those benefits are real. On limited runway, dismissing them as a distraction would be careless.
But the statement of work often contains another proposition. The customer may require a private deployment, a reporting structure built around its internal teams, an approval process that no smaller buyer needs, and integrations that move the product toward one organisation’s architecture.
Each request can sound reasonable on its own. Together, they describe a different company.
This is the part I would examine before celebrating the twelve months. What percentage of the work strengthens the intended product? What percentage exists because this customer has unusual systems, procurement rules, or reporting lines? Who maintains that work after the pilot ends?
A contract can extend the runway while consuming the people who were supposed to use that runway.
Separate reusable learning from paid custom work
The useful question is not whether the pilot matches the current roadmap perfectly. Early products rarely have that luxury. The useful question is what the team expects to learn that will remain valuable after this customer leaves.
A serious pilot should resolve a commercial or product uncertainty.
Will buyers give the system access to the data it needs? Can the AI output survive review by the person accountable for the decision? Does the workflow save enough effort that another company would pay for it? Can implementation happen without the founder sitting inside every meeting?
Write those uncertainties down before work begins. Then connect each requested feature to one of them.
If a custom dashboard helps test whether operations leads will act on the recommendation, it may be useful product work. If it exists because one executive prefers a particular weekly report, price it as customer-specific work and keep it outside the core roadmap.
The same discipline applies to technical choices. A pilot that requires one-off infrastructure may still make sense, but the team should know whether it is buying reusable capability or accepting a services obligation.
This resembles the authority problem in AI Contract Signing: What a Changed Liability Clause Taught Kweku About Authority. The signature can look like the final decision even though one clause has already moved control somewhere else.
Decide what twelve months must prove
“More runway” is too vague to manage.
Twelve additional months should have a defined destination. That might be three customers using the same workflow, a deployment process another engineer can run, or evidence that buyers will renew without a founder-led rescue every week.
The pilot needs boundaries that protect that destination.
Set a limit on customer-specific engineering. Identify the parts that will enter the main product and the parts that will remain separate. Give change requests a commercial price and a roadmap cost. Agree internally on the conditions under which the company will decline an expansion, even if the customer offers more money.
This matters most when the enterprise account becomes the largest source of cash. At that point, every product disagreement begins to feel like a runway decision. The team stops asking what the market needs and starts asking what will keep one invoice moving.
The founder should also model the end of the pilot before it starts. If the contract disappears after twelve months, what remains? Cash is one answer. A stronger product, a repeatable sales case, and implementation knowledge are better answers.
Keep the right to choose the next customer
Microsoft’s 1980 agreement mattered because the company retained the ability to license its operating system beyond IBM. The wider opportunity survived the first important customer.
That is the bridge for an AI or SaaS founder considering an enterprise pilot in Accra, Lagos, Berlin, or New York. The strongest contract gives the customer a valuable result while leaving the startup able to serve the second customer without rebuilding everything.
The decision does not require rejecting custom work. It requires naming it honestly.
Before Monday’s signature, put every deliverable into one of three categories: core product, reusable capability, or customer-specific service. Assign an owner and a maintenance cost to the third category. Then ask the harder question: if the customer doubles the contract but wants the whole team pointed at its private roadmap, would you still recognise the company twelve months later?
The answer belongs in the negotiation now, while the runway clock is still visible and the founder can still choose what the extra time is for.
Comments
No comments yet.