The contract mentions a custom integration. The statement of work describes bespoke functionality. The customer signed because they were promised something built specifically for their workflow.
What they will receive is the standard product with a configuration flag and a support engineer who will manually handle the gaps.
⸻
The Promise Gap
The sales engineer demonstrated the product during the evaluation. The demonstration was honest. The product does what it does.
But during the negotiation, the customer asked for a modification. Something the product almost does but not quite. The sales team, facing the choice between "We cannot do that" and "We can make that work," chose the second answer.
"We can make that work" is the most expensive sentence in enterprise software. It is a blank check written against the engineering team's time that engineering never agreed to fund.
⸻
The Discovery Phase
After the contract is signed, the implementation team meets the customer. They review the statement of work. They read the promises. They begin the discovery phase, which is a polite term for "figuring out what was actually sold."
Within the first week, the implementation team realizes the custom work is larger than estimated, because the estimate was made by the sales team, not by engineers. The scope expands. The timeline stretches. The customer grows impatient because they were told this would take four weeks and it has been six.
The implementation team is now managing the customer's expectations downward while managing the engineering team's capacity laterally, while the sales team has moved on to the next deal.
⸻
The Maintenance Burden
The custom build ships. The customer is satisfied, temporarily.
But the custom code now exists as a branch off the main product. Every subsequent product update must account for this branch. Every bug fix must be tested against this configuration. Every migration must include a step that most customers do not need but this one requires.
One custom build is manageable. Ten is a maintenance crisis. The engineering team spends increasing percentages of their sprint capacity maintaining custom forks instead of improving the core product.
The revenue from the custom deal was recognized in one quarter. The cost of maintaining the custom work is amortized across every quarter that follows.
⸻
The Pricing Fix
Custom work is not wrong. It is under-priced.
If the sales team must promise custom builds to close deals, the pricing model should reflect the true cost: development hours, maintenance burden, and opportunity cost. When the customer sees the real price, they often discover the standard product is acceptable.
The custom build promise persists because the costs are hidden. Make them visible, and the promise becomes an honest negotiation instead of a trap.
End.