A large customer contract deserves a narrower pilot when its compliance requests consume the roadmap needed to learn from the rest of the market. Accept the work only after separating the controls required to prove the relationship from the custom work that would turn your company into one customer’s internal project.
At 4:40 on a Friday afternoon, Malik had the fintech’s security questionnaire open beside a cold cup of coffee in a small office in Accra. He had planned to spend the evening reviewing the next release with his two engineers. Instead, he was reading a request for detailed access controls, reporting flows, approval records, and a set of operational commitments his product did not yet support.
The contract value could fund the team for months. The customer was serious. So were the requirements.
By the time Malik reached the last page, the work no longer looked like onboarding. It looked like a replacement roadmap, one written by a buyer with good reasons to be cautious and no reason to protect a young company’s next learning cycle.
If he signed every requirement as written, the product’s planned validation work would stop. The team could spend the quarter building evidence for one procurement process, while smaller prospects waited for the capability they had actually asked for. If he walked away, payroll would still arrive at the end of the month, and the company would have passed on the clearest revenue opportunity it had seen.
That is the hard part of a large contract. The danger rarely arrives as an unreasonable demand. It arrives as a long list of individually sensible requests.
Read the requirements as a second roadmap
A compliance request can reveal a real gap in how a product is operated. It can also reveal that the customer needs a level of process designed for its own risk profile, scale, and internal accountability.
Those are different categories of work.
Malik started by placing every request in one of three columns. The first covered controls that would make the product safer for every future customer: clearer permissions, better audit visibility, a documented response process. The second covered work that could support a defined pilot, with a fixed scope and a clear end date. The third covered custom behaviour that existed only because this fintech’s internal process expected it.
The third column was the contract trying to acquire the company.
Founders often call this “enterprise readiness” because the phrase feels less alarming. But the useful question is more direct: if this customer disappeared after the pilot, would we still be glad we built this?
If the answer is no, the work needs a price, a timeline, or a boundary strong enough to protect the rest of the roadmap.
The current funding environment makes that distinction sharper. Fintech remains a major part of African venture activity, while investors are paying closer attention to operating maturity, regulatory readiness, and credible paths to scale. Mature operations matter. Building a private version of your product for one buyer does not automatically create maturity.
Turn the contract into a testable commitment
On Monday morning, Malik returned with a different proposal. He did not argue that the fintech’s concerns were excessive. He named the controls his team could support during a pilot, the evidence they could provide, and the workflow they could evaluate together before committing to broader changes.
The conversation changed when the scope became visible.
A pilot can carry real compliance work. It should also answer a commercial question. Will this customer use the product often enough, broadly enough, and with enough conviction to justify the next layer of investment?
That question gets lost when every requirement is treated as a prerequisite for signing.
The useful structure is simple: define the use case, the users, the data involved, the controls available now, and the decision both sides will make at the end. Put the items that require new product development behind that decision point. A customer who cannot tolerate that boundary may need a vendor at a different stage.
This is similar to the decision in why Kwesi narrowed the pilot before expanding the scope. A smaller commitment can protect the evidence needed to make the larger one intelligently.
Protect the learning your runway pays for
The tempting calculation is contract value minus engineering cost. It misses the cost of delayed learning.
Every week spent on customer-specific compliance work is a week when the team may not learn whether its core product solves a repeatable problem. For a small company, that uncertainty is expensive. It can lead to another hire, another delayed launch, or another round of sales conversations built around a roadmap that no longer belongs to the market.
Malik’s engineers still needed to make changes for the pilot. They improved access controls and created a clearer record of key actions. Those were useful changes because the next customer could benefit from them too.
They did not build the customer’s preferred reporting format. They did not promise an open-ended sequence of reviews. The fintech could assess the product within the agreed pilot, and Malik could assess whether the relationship justified further work.
Friday had made the contract feel like a rescue. By Tuesday, it had become a decision with terms.
Leave room for a real no
The strongest boundary is the one a founder can actually keep.
Malik knew the customer could decline the narrower proposal. That possibility stayed on the table while the team waited for an answer. Losing the deal would hurt, and pretending otherwise would have made the negotiation weaker.
But signing an unlimited compliance roadmap would have created a slower failure: a funded team with less room to discover what it should build next.
When the fintech accepted the pilot structure, Malik’s next planning session looked different. The engineers had a defined set of controls to deliver. The planned customer interviews stayed on the calendar. The product roadmap still had space for evidence from outside one account.
That is the outcome worth protecting. A contract should increase the company’s ability to learn and deliver, not quietly decide what the company becomes.
Comments
No comments yet.