Start with the ending. A 90-person specialty food distributor built a custom pricing screen in year one. Three years later they shut it off and rebuilt the same capability using standard features. The traceable spend was $274,000, plus a nine-month delay on every reporting improvement the company wanted.
The original quote was $40,000. Everyone in that meeting thought it was reasonable. Here is what the next three years looked like.
How forty thousand became two hundred seventy-four
- $40,000 to build the screen, as quoted.
- $11,000 in bug fixes during the first year, mostly around edge cases in customer-specific pricing.
- $62,000 to rewrite it when the company upgraded versions — the custom code had to be rebuilt, and the upgrade stalled for seven months.
- $54,000 in elevated support fees across three years, because custom code sits outside standard coverage.
- $38,000 of two employees’ time rekeying pricing that the custom screen failed to apply correctly.
- $47,000 in regression testing across three releases to confirm the custom screen had not broken anything else.
- $22,000 to eventually tear it out and rebuild with standard pricing rules plus one report.
The rebuild took six weeks and worked better than the original. It also required no testing at the next upgrade.
Why the request felt reasonable at the time
Customer service had a real problem. They were quoting specialty pricing from a spreadsheet, and mistakes were costing margin. A screen that showed contract price and current margin next to each line would fix it.
The request was fine. The delivery method was the mistake.
How to say no without losing the room
- Write the requirement in plain language first: “Show contract price and margin on the order entry screen.”
- Ask three people, separately, to describe how they would solve it in the current system. You will usually get one workable answer.
- Price both paths out loud: the custom build plus a three-year support estimate, next to the standard approach plus a report.
- Ask the requester which one they would pick if it were their budget.
- If you still customize, put a named owner and a yearly review date on it. Custom code without an owner becomes permanent.
The rule I give managers is simple: customize when it creates revenue, not when it saves someone four clicks. Most of the requests I see fall into the second bucket, and the second bucket is where budgets quietly die.
That distinction is the heart of good ERP Consulting. The best ERP Consulting advice on a customization request is often a question: what would you do if this feature did not exist? The answer usually costs nothing and ships in a week.
Next time a custom request lands on your desk, ask for the three-year number, not the build number. Then decide.