We have developed one product for payroll processing. We have 10+ customers who are using this software product.

Our existing and new customers are giving us customization changes w.r.t. their needs, and now we are facing the problem of product management. Please give some guidelines to us.

How to manage single software product to multiple customers?

Software developement details :
Front End Tools : Visual Studio 2008 (ASP.net web application)
Source Code Mangement : Visual Source Safe (VSS)
Back End : Sql Server 2005
Team Size: 12


Changes that customers need will fall into one of 4 categories in my experience:

  1. Changes which other customers will find useful but the "initial" customer is willing to pay for.
  2. Changes which other customers will find useful but the "initial" customer is not willing to pay for.
  3. Changes which other customers will not find useful but the "initial" customer is willing to pay for.
  4. Changes which other customers will not find useful but the "initial" customer is not willing to pay for.

For 1, make the changes in the core product and release an updated version to all your customers (you get paid for developing it and you get goodwill going forward).

For 2, make a business decision on if the change is valuable enough to generate further sales to make it worthwhile, if so, make the change in the core product.

For 3, Create some kind of plugin system where you can create a custom add-in component for specific customers.

For 4, I'd recommend not doing this at all.

  • While a useful answer, this seems to be related to "mbas" more than "programmers". But the original question is so vague I don't know if this is what he's asking for or not. – Daniel Kaplan Feb 13 '13 at 20:08
  • What if the changes are small, related to the domain model. For example, adding customer-specific columns to database tables? How do you approach this from a modeling perspective? How can you avoid pushing those extra columns to other clients? – Mvision Feb 10 '16 at 8:43

Fundamentally there are two ways to approach this:

  1. Have a single product that can be customised principally via configuration to suit an individual client's requirements
  2. Build a product for each client based on a standard framework and a common core set of libraries.

The problem with the former is reconciling conflicting requirements from different customers the problem with the latter is that you're now supporting a product per client and that things will drift apart over time. In both cases you want to have mechanisms for managing the specific configuration data for each client.

My personal view is that (without a lot more detail) you're almost certainly better off dealing with a single application - certainly I had reasonable success with feature toggles in a multi-client web application but keeping track was challenging.

Looking at your toolset, there's reasonable support for Themes within ASP.NET and lots of scope for plug-in systems - but you should be looking at updating your tools and especially getting a more reliable/more capable version control system.


In such an application it would be wise to separate the code into generic parts (database driver, widget library), and a configuration part which describes the specific implementation of those generic parts. I would strive to keep the dynamic part as small as possible, and reuse as much as possible. Each customer would have a joint generic part, and a custom configuration part. If any changes are needed to the basic infrastructure, these changes can also be applied to the other customers.

In practice, you could split the software into two repositories, one for the generic part and one for the configuration part, this last one unique for each customer.


This is one of those times where you want to look at configurable options. I know this is an anti-pattern for some cases, but not in this case.

What you need to identify is the areas that clients are looking for customization. Make those the points where you break out configuration files or put values into a configuration db.

Don't go overboard, try to keep the sales team in check with what you can and cannot customize. I have seen this too and it gets very messy very fast.

If these types of configurations are not possible, look at creating interfaces to services or libraries that contain the common code between all clients and the code that is unique. Again the sales team needs to know where these lines are and how expensive it is going to be to create each customization.


I have found a podcast that talks about these issues. Maybe this will be useful for you to listen to.

In this episode Michael interviews one of our regular listeners: Petri Ahonen. Petri introduces Software Configuration Management by defining key terms and describing relevant concepts

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.