Every Custom Feature Comes With Interest

Your biggest customer asks for a special approval workflow. Invoices above a threshold need two managers instead of one, and their finance team wants rejection reasons picked from a fixed list. The renewal is worth far more than the work, so you build it, and it ships in three weeks.

Six months later, four more large customers have asked for their own versions: three approvers instead of two, approval by department, an exemption for trusted suppliers, a different list of reasons. Now there are five variations of one feature, each with its own branch in the code, its own test cases and its own page in the support notes. None of the five was a bad decision on its own. Each was priced on its build cost, and each was agreed with a customer who mattered.

Working on enterprise platforms as a technical lead and solutions architect, I think of a custom request as a product decision before it is an engineering task. The engineering is usually the easy part. The cost is in what happens to the product afterwards.

Every variant is paid for again in every release

A variant is not finished when it ships. It has to survive every release, so someone merges and retests it. It adds a configuration to every test cycle. It has to be carried through every framework or database upgrade. And every support call starts with a question nobody used to ask: which version does this customer have? New engineers inherit all five before they understand one.

That recurring cost is interest, in the sense I used for technical debt: the extra time every change costs while the debt stays. The difference is that custom work takes out the loan in the customer's name and leaves the repayments with you.

The interest also grows in a way that is easy to miss. If customer-specific behaviour is built as independent switches, five of them allow 32 combinations. Pete Hodgson's guide to feature toggles (2017) says testing every combination is unnecessary, and recommends testing the configuration you expect in production, plus the fallback with the new toggles off. For customer variants that advice has an awkward consequence: each customer's setup is a production configuration. Five customers with their own versions means at least five configurations to test in every release, for as long as those customers stay, and every new switch can add more.

Hodgson also describes teams that treat toggles as "inventory which comes with a carrying cost", and try to hold that inventory down. Customer variants are the same inventory, with a contract attached.

Configuration, customisation and a fork are different things

The three words can sound alike in a sales meeting. They come with very different bills.

Source: my own definitions.

To see which one you really have, search the codebase for your customers' names and account IDs. A line such as if (customer.Id == 1042) is customisation, whatever the contract calls it. Configuration reads a setting, such as the number of approvers, and runs the same code path for every customer.

Martin Fowler's advice to companies buying software for a function that does not set them apart was to change their process to fit the package rather than customise it heavily (2010). That is advice for your customer too, and you are allowed to give it. Before quoting the special workflow, ask what job it does for them. The request and the need are not always the same thing, and sometimes the need can be met with a setting you already have.

Price it for its lifetime, then decide what it becomes

Here is a hypothetical example with invented figures. The approval workflow takes 15 days to build. After that it costs about a day per release in merging, testing and support notes, and the product ships twelve releases a year. Over a three-year contract that is 15 days plus 36, or 51 days. A quote of 15 days gives away the other 36, and nobody signed off on the gift.

From the customer's side, a custom feature is a build decision made with your team's hours, and the same lifetime arithmetic applies. Price custom work as the build plus a yearly fee for as long as it exists, and write that into the agreement. A fixed price for the build says nothing about who carries the years after it, so say it explicitly. Then decide what the feature becomes:

• When a second customer asks, stop building variants. The first request tells you about a customer; the second tells you about a market. Turn the feature into product: one implementation, made configurable, with the first customer's version as one of its settings. Generalising costs more than one more variant would. It is still cheaper than the third, fourth and fifth.
• Give every custom variant an owner and an end date. Hodgson describes teams that put expiry dates on toggles, and some that add a test which fails once a toggle passes its date. A custom variant can carry the same test, tied to the contract's review date, so the conversation about keeping, productising or retiring it happens on schedule.
• Keep a register of every variant: the customer, the contract that pays for it, its yearly cost, and its date. If nobody can fill in a row, that variant is already being paid for by everyone else. If you already have five, the register also tells you which to consolidate first: the one with the highest yearly cost and the least revenue behind it.

A custom feature is a loan your customer asks you to take out on their behalf. That can be a good deal. Agree who pays the interest, and for how long, before you sign.

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise software delivery, from pre-sale to handoff.