A renewal can become the wrong deal when the revenue depends on rebuilding your product around one customer. The decision should compare the runway gained with the product, team capacity and future sales the contract would consume.
At 7:58 a.m., Kofi had the renewal agreement open on one screen and the company’s cash forecast on the other. He was an illustrative composite: a founder in Accra, leading a five-person software team, with nine months of runway tied to the signature he expected that morning.
The call began with congratulations. Then the customer’s operations lead shared a new set of requirements.
They wanted approval rules built around their internal structure, reports formatted for a process no other customer used, and a separate deployment path. The renewal was still available, but only if Kofi’s team committed to the changes.
By 8:23, the signature had disappeared from the conversation. The real choice was on the table: accept the work and secure nine months of runway, or refuse it and keep building the product the team believed could serve a wider market.
There was no safe option. Saying no could force layoffs before the next sales cycle closed. Saying yes could turn the company into a development team for one buyer.
The contract had acquired a second price
Kofi’s first calculation was simple. Nine months would give the team time.
That number looked different when he priced the work behind it.
Two engineers would spend most of a quarter on customer-specific changes. The product lead would pause onboarding improvements that three smaller prospects had asked about. Support would inherit a separate deployment with its own failures, documentation and release checks.
The customer was paying for software. Kofi’s company would be committing product capacity, attention and future maintenance alongside it.
This is where renewal decisions often become misleading. Cash arrives as a visible number. Roadmap displacement hides across calendars, support queues and postponed experiments.
I have learned to ask a harder question before treating contracted revenue as runway: how much of the company must remain occupied to keep that revenue?
Nine months in the bank can buy far less than nine months of independent decision-making.
The roadmap revealed what the forecast concealed
Kofi ended the call without agreeing to the scope. He asked for forty-eight hours to return with a proposal.
Then he moved every requested change onto the team’s current roadmap.
The picture was immediate. Their planned self-serve setup moved back. A reliability fix slipped into the following release. The AI-assisted review feature they had been testing with early users lost its engineering window. One overseas prospect would receive no answer on an integration the team had already discussed.
The renewal had rewritten the roadmap before anyone signed it.
That exercise changed the conversation because it forced the contract to compete with named work. “Customer request” sounded urgent but abstract. “Delay the reliability release and abandon the onboarding test” made the trade visible.
This is also why feature cost continues after launch. The code may take six weeks, while ownership lasts for as long as the contract does. I explored that same problem in Feature Cost After Launch: What Support Debt Taught Kojo and Mara About Ownership.
Kofi still faced the possibility that the buyer would reject any smaller proposal. Payroll would not become easier because he had protected the roadmap. For one afternoon, the likeliest outcome was a lost renewal and a much shorter operating horizon.
A narrower offer preserved the decision
With one day left, Kofi returned to the buyer with a boundary.
His team would support the approval logic using configurable rules that could serve other customers. They would produce a standard export instead of reproducing the buyer’s internal report. They would keep one deployment path, with agreed security and access controls, rather than maintain a separate version.
He also separated the work into two parts. The renewal covered the existing product and the reusable additions. Any customer-specific implementation would require its own scope, price and delivery schedule.
The buyer pushed back. Kofi did not fill the silence by promising more.
The revised agreement came through late the following day. It was smaller than the original opportunity, and it preserved enough revenue to avoid an immediate cut. More importantly, the team kept control of the product’s direction.
A narrower contract can still be a strong outcome when it keeps the company able to serve the next customer. The same principle applies when a large prospect demands a market shift before proving demand, as in The US Customer Kojo Hadn't Served, and What Chasing One Could Cost.
Put every renewal request onto the roadmap
The morning after the agreement was signed, Kofi removed the duplicate deployment work from the planning board. The reliability release returned to its original slot. One engineer reopened the onboarding experiment.
The company had less contracted revenue than Kofi expected at 7:58 that first morning. It also had a product it could continue selling.
Before your next renewal call, create a second price for every requested change. Include the work delayed, the people occupied, the maintenance inherited and the number of future customers likely to use it. Then put those costs beside the contract value.
The signature may still be worth pursuing. At least you will know which company you are agreeing to build.
Comments
No comments yet.