The Hidden Cost of Custom Customer Features

Freshness Warning
This blog post is over 1 year old. It's possible that the information you read below isn't current and the links no longer work.

Surprised child

The CEO sends you an email. "Skyhook Industries wants to know if we can add some features so they can use us for their water treatment division. They’re one of the largest customers of our highway construction management product. Can we add their water treatment features and keep them happy?"

You reply that the product team saw this request already and learned that none of your other construction customers would find the feature useful. The company had no plans to start selling to the water treatment industry. The feature would be used by Skyhook and only Skyhook. You had told the customer that you would not be adding the requested feature.

The CEO comes back to you later. Skyhook’s management is willing to pay your company $50,000 to develop the feature. It’s not complicated to build, so a junior developer could build it. $50k is half a junior developer’s salary, and it certainly won’t take them 6 months to build. Sounds like pure profit and you make a top customer happy.

This is a common story at software companies all over. A customer wants a pet feature. Something no one else will ever use, something that doesn’t fit your product vision. Usually, this is a very large customer and you’re afraid they’ll leave if you don’t say yes. Sometimes this is a smaller customer that’s promising to become a huge one if only you could do this one thing. Sometimes they’re not a customer at all but promise to buy the product if you take care of their special need. Often, the customer is willing to pay you to build it.

Sounds like a win all the way around. But it’s not.

Don’t do it. The cost of building and maintaining the one-off feature will greatly exceed anything you might charge that customer. You’ll charge them for the initial investment. You might overcharge them a whole lot because you know there will be ongoing maintenance costs. You won’t charge them enough.

That one custom feature will need more maintenance than anyone expects. You will need to test every new capability that you develop both with this new feature and without it. It’s an exponential growth to your testing. You don’t test N times. You test N^2 times. Add a second one-off feature to the product and the exponent grows. Now you’re testing N^3 times.

The ongoing development cost isn’t limited to making sure the product doesn’t have bugs with this feature. The cost of designing and developing new features goes up. You have to ensure that each new thing you build works in the right way with this custom feature. Take for example a custom report filter you added for a customer. The customer will expect that this report filter continues to work on their existing reports. That’s testing. They’ll also expect that the custom filter works on every new report you add to the system over time. You’ve added extra overhead to everything that the custom feature could conceivably touch.

Your special, super-important customer will become the customer with the most outages and quality problems. It’s a truism in software development that most issues happen in the least-traveled part of your codebase. At some point in your product lifecycle, you’ll miss a test. You’ll forget to update a server with the custom code. You will make a feature change that you didn’t realize affected the custom feature.

Besides increased development costs and pitfalls, your support and documentation efforts will cost more. You’ll need to produce docs both with and without the feature. Train your support staff on not only the feature, but how it interacts or alters the rest of the product, and how to identify when that feature exists. When you inevitably build a new capability that doesn’t interact with the custom feature in the way the customer expects it would, support will hear about it.

Every choice you make in the product has trade-offs. The presence of a capability can limit your future choices. It can paint you into design corners. Having a one-off makes that harder. The thing that’s limiting your choices isn’t even used by most customers. Changing or removing it is impossible because the customer paid for it.

There are soft costs associated with one-offs, too. Now that you’ve done it once for them, it’s easier for the customer to ask for more, and harder for you to say no. You can’t ever uncross that line with that customer.

An unexpected soft cost is the drain on employee morale that comes with the politics of having "special" customers. You’ll hear your team talking about these customers with negative tones. "We can’t build it that way because 'Acme.'" "Why is that test failing? Acme."

Your customer or sales team will get creative. "What if we build it as a custom module that’s only installed for them and they own the code and are responsible for all updates, and they do all testing?" Sounds reasonable. Then Bond, Inc. asks for and gets their own custom module. You find you can’t have Skyhook’s module running at the same time as Bond’s, so now you need to test the product with Skyhook and Bond both there. Skyhook says it’s not their responsibility to make sure Bond works. And Bond says the same thing about Skyhook. Who is going to pay for that test?

The costs to create and maintain a one-off feature are far more than the development time required to initially build the feature. Even those that anticipate the ongoing maintenance costs underestimate the extent of those costs. It is not unusual to spend fifty times as much over the customer lifetime as you spent to build the feature. And the irony is that you did the work to make the customer happy but you destroyed whatever goodwill you had with the customer instead.

Recently Written

The Trap of The Sales-Led Product (Dec 10)
It’s not a winning way to build a product company.
The Hidden Cost of Custom Customer Features (Dec 7)
One-off features will cost you more than you think and make your customers unhappy.
Domain expertise in Product Management (Nov 16)
When you're hiring software product managers, hire for product management skills. Looking for domain experts will reduce the pool of people you can hire and might just be worse for your product.
Strategy Means Saying No (Oct 27)
An oft-overlooked aspect of strategy is to define what you are not doing. There are lots of adjacent problems you can attack. Strategy means defining which ones you will ignore.
Understanding vision, strategy, and execution (Oct 24)
Vision is what you're trying to do. Strategy is broad strokes on how you'll get there. Execution is the tasks you complete to complete the strategy.
How to advance your Product Market Fit KPI (Oct 21)
Finding the gaps in your product that will unlock the next round of growth.
Developer Relations as Developer Success (Oct 19)
Outreach, marketing, and developer evangelism are a part of Developer Relations. But the companies that are most successful with developers spend most of their time on something else.
Developer Experience Principle 6: Easy to Maintain (Oct 17)
Keeping your product Easy to Maintain will improve the lives of your team and your customers. It will help keep your docs up to date. Your SDKs and APIs will be released in sync. Your tooling and overall experience will shine.


What I'm Reading


Adam Kalsey

+1 916 600 2497


Public Key

© 1999-2022 Adam Kalsey.