X : One of our customers wants a new feature in our product.
Me : Sounds good. Add it to the backlog.
X : No other customer seems to want this. It's unique to them.
Me : Is it a generally useful feature that others might want?
X : I doubt it
Me : Then super low priority.

X : But they're willing to pay.
Me : Sure but that means taking resources of your priorities.
X : They're willing to pay a lot.
Me : More resources? Covering all the costs, now and in the future?
X : Yes
Me : Tell them it's a bad idea, try to persuade them not to.

X : They really want this.
Me : It seems you've already decided.
X : Yes. Any advice on how to manage this.
Me : Fairly easy, take a fork of the code base into a new repository. It's a new project. Work on it there. It'll need its own infrastructure, testing and support regime.

X : What about syncing bug fixes with the original and this new version?
Me : What? No. It's a new project. It doesn't get upgrades / bug fixes or anything from the existing project. It's a split, a seperate path. New features in the existing product don't get added.

X : But how do they get new features?
Me : They pay for them, a new development team etc to port over bug fixes and upgrades into this fork. Ditto with support, they need a new support structure etc. This "feature" they want enforces a split, it may as well be a new company.

X : Oh my god, that'll cost a fortune.
Me : Yes, which is why it's a good idea to explain to them why this is a really bad idea. Don't get sucked into shouldering these costs yourself.

X: They're looking to pay for the development of the feature not the maintenance of the entire code base.
Me : Well, that's unrealistic expectations on their part. You need to have that conversation.

X : Can we expose the systems as APIs, so they can build themself?
Me : I thought you said this was a product? Even so, subcomponents of the system maybe evolved enough to provide as API like services. You really need to map it and then add such requests to your backlog.

X : Why can't we expose the whole thing through APIs?
Me : You could. But if it's not evolved then it'll change and those APIs being embedded in other systems will rapidly become a hindrance to change. Choose wisely what you "API" ... ps, use a map.

X : Basically you're saying it's a bad idea?
Me : Well, it's not a good idea.
X : Any ideas on the cost?
Me : With no context? A rule of thumb?
X : Yes
Me : Based upon past experiece, then a $50K cost in development hours would be north of $1M over time if all costs included.

X : You're kidding?
Me : No. It's a really, really bad idea. Don't do it.

X : I don't see why we can't have a common base and then add on modules?
Me : Common base X1 and a standard module Y i.e. X1+Y. Now add a custom module Z i.e. X1+Z. When you upgrade the common base X1 -> X2 which is tested with Y i.e. X2+Y, who pays to test / bug fix X2+Z?

If you haven't had the conversation, then the client will expect a) to get new features i.e. X2+Z and b) blame you if X2+Z doesn't work. So you get lumbered with ongoing costs. If you had many modules this becomes a nightmare. Once customised they get X1+Z until they pay ...

... i.e. they should pay for any testing or porting from X1+Z -> X2+Z. This is the ongoing cost, it's not just the development of Z. The same with costs associated with support, with bug fixing etc etc. With many modules the overhead and complexity can be messy. Avoid this path.

X : Why the high cost?
Me : Continuous porting, testing, divided focus, impacts on morale because of politics (i.e. special clients) and worst of all ... once you open the door, there's always one more "special" feature that the now designated "special" client wants. Argghhh.