A feature request attached to a major contract deserves a separate product decision, not an automatic yes. Accept it only if the work strengthens the direction you already chose, can be contained, or earns enough to fund the cost of serving a different market.
At 6:18 p.m. in Accra, Kwame was holding his laptop open with one hand and stirring groundnut soup with the other when the email arrived. The procurement lead at a fictional logistics company had attached a draft contract, the first one large enough to change his startup’s runway. One paragraph stopped him: they wanted every approval rule configurable by region, business unit and employee grade before launch.
Without that capability, the prospect could walk. With it, Kwame could spend the next quarter rebuilding a simple approval product around one company’s internal structure while his existing customers waited for the fixes they had already requested.
The contract changed the size of the request
Before the email, Kwame had rejected similar requests in minutes. His product helped small operations teams send routine expenses to the right manager. Customers could choose an approver and set a basic threshold. That was enough for the job they had hired it to do.
The attached contract changed how the request felt. Its value could extend runway, give the team a recognisable customer and quiet the weekly anxiety around payroll. The feature started to look reasonable because the buyer had placed money beside it.
That is where founders can confuse commercial importance with product evidence.
A large prospect proves that one organisation will pay under stated conditions. It does not prove that existing customers need those conditions, that future customers will accept the added complexity, or that the resulting product will remain economical to maintain.
Kwame needed to price the whole decision. Engineering time was only the first line. The team would also inherit configuration screens, migration rules, support questions and a sales process that now had to explain a more complicated product. Every later feature would need to work across the new permission structure.
The contract offered revenue. The request created a new operating model.
Separate the customer’s job from their proposed feature
The next morning, Kwame wrote the prospect’s request on a whiteboard in his small office near Osu. Then he removed their solution and wrote the underlying job beneath it:
“No expense should reach the wrong approver.”
That sentence gave him room to think.
The buyer had proposed a full rule builder because their organisation already thought in regions, units and grades. Kwame’s team did not have to reproduce that hierarchy inside the product to solve the immediate problem. They could explore a narrower mapping during setup, limit changes to an internal tool, or handle one approved structure for the first deployment.
This is the same distinction that matters when a founder considers hiring before validating demand. The salary or build cost is visible; the direction it commits the company to is harder to see. I explored that tension in Should I Run Friday Payroll or Hire an AI Engineer Before Testing Demand?.
Kwame returned to the buyer with three boundaries. The first release would support their current approval structure, changes would pass through his team during the initial period, and a general rule builder would stay outside the contract. He also separated deployment work from the recurring subscription so the price reflected the work created by this customer.
The procurement lead did not accept immediately.
For two days, the contract sat unsigned. Kwame knew the alternative was clear: remove the boundaries, secure the deal and begin the quarter with a roadmap already owned by someone else.
Use reversibility to judge the exception
A customer-specific request becomes less dangerous when the team can isolate and reverse it. The key question is practical: if this customer leaves in six months, what remains inside the product?
If the answer includes permanent screens, new data structures and support obligations for capabilities nobody else uses, the contract is pulling the product into a separate market. That may still be a sound choice, but it should be treated as a deliberate change in company direction.
A contained configuration carries a different risk. The team can serve the customer, learn how the workflow behaves and remove the setup later without forcing every customer through it.
This was Kwame’s strongest reason for refusing the full builder. He had no evidence that small teams wanted to design approval logic. His existing customers wanted fewer decisions, not a system for expressing more of them.
A similar boundary appears in private deployments. One buyer’s security requirement can consume months of work and quietly split a product into two versions. Kojo’s private deployment dilemma examines what happens when the valuable contract and the costly exception arrive together.
Make the buyer choose with you
On the third afternoon, the procurement lead called. Their operations manager had reviewed the narrower setup and believed it could cover the launch. They kept the full rule builder out of the contract and added a review point after the first deployment.
The deal still had risk. The manual setup could become burdensome. Another department could demand a different structure. The customer might later decide the boundary was unacceptable. Kwame had bought evidence, not certainty.
A week later, the signed contract sat beside his laptop while his team worked on the reliability fixes already promised to current customers. The new account would require extra care, but it had not taken control of the product.
That is the useful test when a large request arrives beside a signature line. Put the prospect’s proposed feature aside. Name the job, calculate the permanent obligations and offer the smallest reversible way to learn.
Then let the buyer respond to the boundary. A contract worth taking should survive an honest account of what your product will become to fulfil it.
Comments
No comments yet.