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.
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.
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.
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.
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.
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.
Me : Well, that's unrealistic expectations on their part. You need to have that conversation.
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.
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.
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.
Me : No. It's a really, really bad idea. Don't do it.
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?
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.