A European enterprise logo is worth pursuing only when the contract matches what the product can reliably do today. If the agreement requires payment-data controls, response times or audit evidence the team cannot provide, the founder should narrow the promise before signing.
At 4:47 on Friday, Chinedu received the contract on his phone while packing his laptop into a fraying black backpack in Lagos. He ran a five-person fintech company, still reviewed failed transactions himself, and had spent four months trying to get this buyer through procurement. Chinedu is an invented composite, but the decision in front of him is common enough: the customer was ready, the product was useful, and the paperwork assumed a much more mature company.
The signature deadline was Monday morning.
The logo came with promises hidden in the contract
Chinedu expected clauses on confidentiality, payment terms and ownership. Instead, he found commitments about payment-data retention, incident reporting, system availability, audit access and deletion requests.
The sales conversation had focused on what the product did well. The contract focused on everything that could go wrong.
One clause appeared to require a response within a timeframe his team could not consistently meet outside working hours. Another described data deletion as though every customer record lived in one place. In reality, transaction references appeared across the main database, support exports and logs used to investigate payment failures.
The customer’s name would make future conversations easier. It might reassure investors, attract stronger candidates and give the company revenue it badly needed. Chinedu could already picture the logo on the pitch deck.
He could also picture the first serious deletion request arriving during an incident.
If he signed unchanged, his company might begin the relationship in breach before the first user logged in. If he pushed back, procurement could choose a larger vendor and close the file. There was no safe-looking option left.
A contract can expose the product you have avoided seeing
I would not start by asking whether the customer was prestigious enough to justify the risk. I would translate every operational promise into a test the team could run on Monday.
Can we locate every copy of one customer’s payment data?
Can we delete it without damaging records we are required to preserve?
Can we produce evidence of who accessed it?
Can someone meet the incident commitment when the engineer who understands the payment flow is asleep, travelling or handling another failure?
That translation changes the decision. Legal language can feel distant until a clause becomes a person, a clock and a broken workflow.
Chinedu opened a spreadsheet and gave each promise one of three labels: true now, achievable before launch or unsupported. The third category mattered most. “We will build it later” carries little weight when the contract says it already exists.
He found seven unsupported promises.
Two required product work. Three needed an operating process with a named owner. The remaining two could not be met without changing how the company stored and traced payment data. Those were contract problems and architecture problems at the same time.
The exercise resembled the risk hidden in the shared spreadsheet the demo did not account for. The visible workflow worked. The evidence trail underneath it did not.
The useful negotiation was smaller than the sales pitch
By Saturday evening, Chinedu had stopped debating whether to accept or reject the whole deal. He prepared a narrower proposal.
The company would support a limited pilot with a defined group of users. The contract would describe the controls already operating, remove commitments the team could not verify, and place the remaining requirements behind launch conditions. Each condition would have an owner and a test.
This approach still carried risk. The buyer could refuse. A procurement team comparing vendors may have little patience for a founder rewriting its standard terms.
But Chinedu now had a defensible position. He was no longer asking the customer to trust future engineering. He was showing where the current boundary sat and what would need to change before that boundary moved.
The distinction matters because enterprise contracts often convert roadmap pressure into legal exposure. A requested feature can slip. A signed obligation can become evidence that the company promised something it knew was incomplete.
That is why I would protect the roadmap and the contract together. The reasoning is close to the choice in Kojo’s enterprise pilot: define the smallest useful commitment, then calculate what it displaces before agreeing.
Monday’s signature had fewer promises
At 8:26 on Monday, Chinedu sent the marked-up agreement and the pilot conditions. He did not attach a long explanation. The document showed which commitments the company could accept, which needed revised wording and which would become valid only after verification.
The enterprise logo was still uncertain. So was the revenue.
What had changed was the company’s exposure. Chinedu could now lose the deal for telling the truth about the product, rather than win it by making promises his team could not keep.
Before signing your next enterprise agreement, take one customer record and follow it through every database, export, log and support tool. Then read each data clause again with that record open in front of you.
Comments
No comments yet.