Turn a one-customer product into one you can sell to many

What changes for you

Your product started as a project for one client. It did what they needed, they were happy, and then someone else asked for the same thing. Saying yes was easy: you took a copy, changed the name and a few details, and handed it over. By the third or fourth customer, the cost of that yes is showing. A fix made for one copy has to be repeated in the others, or it is forgotten. A small change one customer asked for has quietly turned their copy into something nobody else runs. Each new customer adds another product to look after, and the work grows with every sale.

What the business needs is the opposite: one product that serves many customers, with each customer seeing only their own data. A fix is made once, for all your customers. A new feature is built once, and you decide who gets it. Signing a new customer no longer means starting another copy.

For you, the change is that selling the product stops being a burden on the people who keep it running. The question in a sales call moves from “can we afford one more copy” to “is this customer a good fit”. Everything we build for this lands in your own repository, and it is yours.

This page is about turning several copies into one product. If the hardest part of your situation is an old internal system your staff work around, replacing the back-office system is closer to it. If the copies have left you with a codebase that slows every change, paying down technical debt while features keep shipping covers that.

What you decide

You decide what the shared product is. Your copies will have drifted apart, and not every difference deserves to survive. Some changes one customer asked for are worth offering to everyone, some belong only to that customer, and some can go. You make that call for each one, with the customers’ needs in view.

You decide which customers move across, and in what order. Some companies start with the newest customer, whose copy has drifted the least. Others start with the copy that costs the most to keep up. The first client, who has been with you the longest, can wait until you are confident.

You decide what each customer sees when they move. What stays familiar, what changes, and how you tell them about it are part of your relationship with each one, and we would rather settle that with you than assume it.

You decide how you sell the product from here: which customers you pursue, and what you offer them. That is your business, and nothing on this page decides it for you.

You decide what ships. Nothing reaches your users without your approval.

What you see along the way

You see the shared product take shape in your repository, as small changes your team can read and approve. A choice that is yours, such as whether a difference one customer depends on becomes part of the shared product, reaches you with the question and a link.

What it costs you in time

A first conversation about the product, the customers who use it today and how their copies differ. After that, some time from whoever knows each customer best. They know which differences matter to that customer and which were a one-off request, and that knowledge decides what the shared product keeps.

What if you want to stop

Whatever you have approved by then remains in your repository. Customers who have not moved keep their own copy and carry on as they did before. Your code and your product stay yours to take anywhere.

Starting small

We have not turned a customer’s product into one that serves many customers yet, and we will not suggest otherwise. A sensible first piece is to compare two of your copies with you, agree what the shared product keeps, and move one customer across, so you can see it working before deciding on the rest. Every engagement is tailored to your product and your goals. It starts with a conversation, with no obligation.

Questions leaders ask

Do our current customers have to move to the new product at once?

No. Who moves, and in what order, is your decision. Many companies start with the newest customer, or with the one whose copy is the hardest to keep up, and leave the first client where they are until everyone is comfortable. Each customer's move is settled with you before it happens.

Our first client paid for the product. Does this change what they own?

That is a question for your agreement with them, not one we can answer for you. What we can say is that the code we build for you is yours and lands in your own repository. If your first client has rights in the original work, raise that early, so the plan for one product fits what you have already agreed.

Will our customers notice the change?

That depends on what you choose to change. You decide what each customer sees and what stays familiar to them, and nothing reaches your users without your approval. We would rather plan each customer's move with you than promise on this page that it will go unnoticed.

What if one customer needs something the others do not?

That is one of the first choices you make. Some differences belong in the shared product, some become settings a customer can have or not, and some are better declined. Where to draw that line is a business decision as much as a technical one, and it stays yours.