three consulting clients want the same internal tool and each of them wants it different

Before any of the architecture, go and read the contracts you signed. In consulting agreements it is common for work product to belong to the client, sometimes including anything created during the engagement. If all three contracts say that, you do not have a product, you have three clients who each own a copy.

This is fixable and the fix is a conversation, not a lawsuit. Most clients will happily agree to a licence-back or a carve-out for reusable components because they do not want to be in the software business. But have that conversation before you launch a public product built on the same code, not after one of them notices.

The uncomfortable question: are they renewing because of the tool, or because of you? You said the tool is why they renew, but they are also paying $5,800 a month for someone who understands their reconciliation mess and answers the phone. Those clients are not evidence that a $99 product will sell, because they never bought a product, they bought your attention.

I am not saying do not do it. I am saying test the product on someone who has never met you before you restructure your income around it.

Write out every requirement from all three, in one list, and mark each one as either core, configuration, or bespoke. Core is anything all three need. Configuration is where they need the same capability with different settings — field mapping, output destination, schedule. Bespoke is where one of them wants something structurally different, like the approval step.

The product is the core plus the configuration. The bespoke items are either a paid add-on or they stay as consulting, and it is fine for them to stay as consulting for a long time.

The mistake I made was treating a bespoke item as configuration because the client was important. That one feature had its own data model and it dragged on the whole codebase for two years.

Doing this right now with two clients. The thing that unblocked me was writing the configuration as a file per client and putting those files in the repo. Suddenly the differences were visible in one place, and about two thirds of what I thought were code differences turned out to be four field names and a schedule. Boring, but it turned a vague fear into a diff I could look at.

One codebase, one deployment, config per tenant, and the bespoke bits behind flags you charge for. Never fork. A fork feels faster for six weeks and then it is a second job.

On the money transition, since dropping from $5,800 to nothing is not an option: keep the retainers and change what they buy. Renegotiate each one so a portion is a licence for the tool and the rest is a smaller advisory retainer. Your income barely changes, but you now have three paying licences, a price you have tested, and a reason to keep the codebase single.

Then take the hours the reduced advisory work frees up and spend them on customer four, who is a stranger. That is the actual transition and it usually takes a year, not a quarter.