Ughhh I hate difficult customers.

@helenS In our case you can just implement a kill-switch that, if they don't pay the amount due, will make the product stop working 😌 unfortunately that's not always applicable to other sectors

@Elessar My favorite is selling them something that's already in the program, just turned off by a flag. "Implementing additional functionality" just means setting that flag from 0 to I.
If Redmond can do it, I can do it too 😏

@helenS A popular AAA game a while back was caught doing this, they sold a DLC (expansion) that would only patch a .dll in order to enable some logic that was purposefully suppressed in the main game

@Elessar I don't think it's illegal.

@helenS Not at all, maybe unethical/unfair at most. But as far as I know, not illegal.

@Elessar I can't see a significant difference between
(a) module is already installed, just de-activated and becomes fully functional after purchase
(b) module is sold separately and will be installed after purchase

Can you?

@helenS It depends on how you market it, I think. If it's something that becomes available after launch, and that you market as a (paid) update, it shouldn't be just a feature-switch imo.

If it's just different "editions" of the program, then it's well established in the industry (think of even things like Windows, the only practical difference between Home, Pro, Enterprise editions is probably the set of compiler constants it's built with).

@Elessar For example I have a module that writes dunning letters. It's sold separately but it's already in the program.

@helenS Yeah, well, I assume your customers know they can get it when they buy the main program, right?

What I would find unethical is, for instance, if you tell them that you need to work on it, charge them on the working time, and then eventually deliver a feature switch. Which would still be legal, technically, but if a supplier of mine did a similar thing and I found out, chances are that I personally would replace this supplier.