An enterprise logo is worth taking only when the contract pays for the uncertainty it introduces. If nobody can calculate the implementation cost yet, the founder should narrow the commitment before accepting the revenue.
At 4:47 p.m. in Lagos, Tunde had thirteen minutes before the offer expired. He sat in a small meeting room with his laptop at 9 percent, reading the same implementation clause for the fourth time while his co-founder waited on a call. Tunde is an invented composite, but the decision is familiar to founders selling young products into large companies.
The contract could give their Nigerian fintech its first recognisable enterprise client. It could also consume the team for months. The buyer wanted custom approval rules, historical data migration and integration with an internal system nobody on Tunde’s team had seen.
At 5:00, the signature window would close. Without the deal, the company would enter the next quarter with limited runway and no large customer to show prospective investors. With it, four engineers might spend the quarter building around one buyer’s internal process while the product roadmap stopped moving.
The revenue number hid the real commitment
The contract showed what Tunde would receive. It did not show what he would give up.
That second number was spread across unanswered questions. How clean was the historical data? Who controlled the internal system? Would the buyer provide technical documentation before implementation began? How many approval layers had been described as “minor configuration” during the sales call?
A fixed contract value beside an undefined implementation scope creates a comforting illusion. Revenue is visible, while engineering time, support load and delayed product work remain blank.
I have learned to distrust that blank. A request can sound small because it fits into one sentence. “Connect our existing records” might mean a clean import from one standard file. It might mean weeks of correcting inconsistent fields, tracing duplicates and waiting for decisions from people who were never included in the sales process.
The same problem appears when a polished demo meets the buyer’s working reality. I wrote about that gap in the shared spreadsheet the demo didn’t account for. The hidden work usually enters through ordinary details, then expands after the contract has removed your room to negotiate.
Tunde priced the unknown before pricing the work
At 4:51, Tunde stopped trying to estimate the full implementation. He could not produce an honest number with the information available.
Instead, he separated known work from discovery.
The standard product setup had a boundary his team understood. Data migration, internal integration and custom approval logic did not. Those items needed access, technical review and decisions from the buyer before either side could define the work.
This changed the question. Tunde no longer had to decide whether every possible implementation task fit inside the contract value. He had to decide whether the contract gave his team a safe way to learn what those tasks were.
It did not.
The agreement treated every requirement discussed during procurement as included work. There was no paid discovery phase, no limit on migrated records, no named technical owner on the buyer’s side and no process for approving additional scope. The enterprise logo looked valuable because everyone outside the implementation meeting would see it. His engineers would carry the cost privately.
The safest signature changed the shape of the deal
At 4:55, Tunde sent a narrower commitment.
His company would accept the standard deployment under the proposed commercial terms. The uncertain work would begin with a separate, paid discovery period. After reviewing the data and internal system, both teams would agree on scope, delivery dates and price before development started.
The buyer could reject that change. The contract might disappear at 5:00, leaving Tunde to explain why he had let the company’s largest prospect walk away.
For three minutes, nobody replied.
At 4:58, the procurement lead asked whether the discovery fee could be credited toward implementation if both sides continued. Tunde agreed. The deadline passed while the revised wording was still being reviewed, but the buyer kept the conversation open.
That was the turn. He had stopped treating the deadline as proof that the original terms were acceptable.
A similar boundary can protect a small team when one enterprise pilot begins to own the roadmap. Kojo’s six-person team faced that choice. The practical move is to make uncertainty visible before your engineers absorb it.
What must be true before you sign
When implementation cost cannot yet be calculated, I look for four conditions in the agreement: a defined standard deployment, a paid way to investigate unknowns, a buyer responsible for access and decisions, and a written process for changing scope.
These conditions do more than protect margin. They reveal whether the customer can participate in the implementation they are buying.
A large company may have the budget and still lack an available technical owner. Its data may exist and still be unusable. Its internal stakeholders may agree on the purchase while disagreeing on the workflow. Your contract cannot solve those problems, but it can stop your startup from funding them without a limit.
The following morning, Tunde’s team opened their planning board. The product work was still there. Beside it sat a short discovery project with an owner, a fee and a decision point.
The logo could wait. For the first time since 4:47, the cost had somewhere to become visible before it became theirs.
Comments
No comments yet.