A contract that funds another year is worth signing only if the work strengthens a capability, customer insight, or distribution path the product already needs. I would reject it when most of the revenue depends on private requirements that cannot become part of the product without displacing the roadmap.
Consider Kojo, an invented composite of founders I have watched face this decision. At 9:40 on a Thursday evening in Accra, he was holding a printed contract beside a laptop showing the company’s runway. The prospective client would cover salaries for another year, but wanted his four-person product team to build an approval system, reporting dashboard, and data export designed around one internal process.
The signature deadline was Friday. If Kojo declined, he might have to pause a senior engineering hire and tell the team that runway had become the main constraint. If he accepted, the product they had spent eighteen months building could disappear beneath six months of client requests.
Both outcomes could damage the company. That is what made the contract difficult.
Revenue can hide a change in business model
A large contract can look like validation because money has finally reached the table. Yet customers pay for different reasons.
One customer may pay because your product solves a problem shared by an identifiable market. Another may pay because your engineers are available to construct exactly what its organisation needs. The invoices can look identical while the businesses underneath them move in opposite directions.
I have learned to inspect the obligations rather than celebrate the contract value. Who decides what gets built each month? Can the client delay acceptance because of a requirement that serves only its internal process? Will engineers spend their time improving the core product, or maintaining a second system with the company logo attached?
Those questions expose the actual transaction. If the client controls the roadmap, acceptance criteria, and release schedule, the team has probably sold development capacity. That can be a sound business, but founders should name the change before signing for it.
The danger grows when runway is short. Twelve more months feels like safety, so every custom request starts to sound temporary. Three months later, the strongest engineer knows the client’s workflow better than the company’s own product, and each promised delivery makes returning to the roadmap harder.
Apply the reusable-work rule before signing
My decision rule has three parts: the contract should fund work we already need, produce learning we can reuse, and leave the team free to say no to client-specific additions.
I would ask the team to mark every promised deliverable as core, reusable, or private.
Core work already belongs on the roadmap. Reusable work serves this client first but could reasonably help other customers without carrying the client’s internal terminology or process into the product. Private work exists because this particular organisation operates in a particular way.
Then I would calculate the burden in engineering weeks, including integration, review, documentation, support, and the awkward fixes that arrive after launch. Contract value alone gives a false picture. The useful comparison is revenue against the months of product capacity surrendered.
A small amount of private work may be acceptable when it opens a market the team has deliberately chosen. The contract becomes dangerous when private work dominates, reusable work depends on optimistic assumptions, or the client can keep expanding the scope through ordinary review meetings.
This is similar to deciding whether to pause a senior engineering hire when the roadmap exceeds the runway. The uncomfortable step is forcing the plan to admit which constraint is real.
Protect the right to return to the product
Kojo’s turn came late that night. He stopped asking whether the contract was large enough and asked whether the company could return to its product after delivering it.
The honest answer was no.
Most of the requested work used the client’s internal categories. Acceptance depended on several departments. The proposed integration had no clear use for the customers already on the product. Worse, the agreement gave Kojo little room to refuse additional changes connected to the initial scope.
He did not need to walk away immediately. He rewrote the offer around a paid discovery period, one core integration, and a defined pilot using the existing product. Custom reports moved outside the initial scope. Any new requirement would need separate commercial approval and an explicit decision about whether it belonged in the product.
The client could have rejected those terms. That possibility remained real when Kojo sent the revision on Friday morning. Losing the contract could still mean a hiring pause and a shorter plan.
But the revised proposal made the decision legible. If the client wanted the product, there was a deal to make. If it wanted a dedicated software team, the contract needed consulting economics, staffing, and management built for that business.
Put the constraint on one page
Before signing a similar contract, write down four figures: months of runway gained, engineering weeks committed, percentage of deliverables that are private, and the earliest date the full team can return to the roadmap.
Then add one sentence: “After this contract, we will know or own something that improves the product because…”
If that sentence depends on “exposure,” “relationships,” or the hope that bespoke work may later become reusable, stop. Those are possibilities, not assets.
Kojo’s revised contract was still open when he closed the laptop. The company had no guaranteed year of funding. What he had instead was a boundary the team could price, defend, and use again on the next sales call.
Comments
No comments yet.