Mutualised Software Solutions: A Growing Trend

Over the past year, PeopleWeek has noticed increasing interest in mutualised HR software solutions. In this article I explain what a mutualised solution is, the main drivers and benefits of this approach, as well as the disadvantages.


In simple terms, a mutualised solution in software is either a new platform, a new module, or a new feature that is collectively purchased (by clients) and sold (by the software company) to more than one independent organisation.

In PeopleWeek’s experience, mutualised solutions fall into one of the following three categories:

  1. A tender, or Request for Proposals, is issued by several organisations that are looking to implement a similar software solution;
  2. The software company is proactively approached by existing clients with a collective request to develop a new solution. This may happen as the result of shared clients knowing each other or even from spending time together at industry events and networking sessions; or
  3. The software company proactively approaches a group of existing clients to ask them whether they are interested in contributing to the development of a new solution that will subsequently be deployed to a group of customers.   


This needs to be looked at from two perspectives: 1) software clients and 2) software companies.


The main driver of mutualisation is financial/budgetary and there are two reasons for this:

  1. Purchasing the same solution as part of a group of organisations increases the clients’ purchasing and negotiating power. This is particularly the case in RFPs.
  2. Sharing the costs of software development (design, development, testing, deployment) amongst several organisations.

There are other important drivers of mutualisation:

  • Smart design: Technology is a means to and end. It enables processes. When a solution is designed to be used by multiple organisations – that may have very similar or even slightly different existing processes – it encourages broad thinking, sharing of different practices, and may ultimately lead to improvements (e.g. user experience, efficiency, etc).
  • Smart technology: Technology built to work for multiple organisations is likely to be designed smartly as it needs to cater to slightly different needs (e.g. different configurations within the same underlying technology).
  • Simplification: Mutualised designs often result in a “90/10” or “80/20” solution for each organisation. They may not get all the “bells and whistles” they would like in the perfect solution but this may be helpful in forcing them to simplify existing processes or steps that are too complex relative to the value they add (and perhaps too expensive from a technology point of view).
  • Speed of implementation: Technology companies will invest more time and people on a project if it is being developed for multiple clients and they have a guaranteed client base (i.e. future license buyers).

Software Companies

There are multiple reasons why software companies should be open to mutualised solutions:

  • Client satisfaction, i.e. be responsive to client needs and offer value for money.
  • Evolve their technology (improve and enrich their software’s functionalities).
  • Win RFPs, i.e. acquire new clients.
  • Develop new technology with a group of beta clients that will help them to design and test it.


Again, this question needs to be looked at from the perspective of clients and software companies.


There are two main downsides of mutualised solutions for clients:

  1. As mentioned above, mutualised developments tend to be a “90/10” or “80/20” solution for each organisation. It is not a customised solution.
  2. There may be an upfront time investment to build alignment on the common needs (and, conversely, agree what needs to be different). This alignment building typically needs to be done before approaching the software company because you need to be confident that there is, indeed, sufficient alignment to make a common solution viable.

Software Companies

There are three potential downsides for software companies when developing mutualised solutions:

  1. As with clients, it may be necessary to invest time to finalise alignment on the common needs and identify unavoidable differences.
  2. The technology solution will often be more complex from a development point of view because it will need to cater for client differences. This means that whilst all clients will be using the same underlying technology (code, architecture), the solution may need to contain a high degree of configurability.
  3. It may be incompatible with the existing pricing model. This is an important point and merits a paragraph on its own…

Unfortunately, the historical pricing and operating practices of most technology companies – past and present, large and small – are the polar opposite of mutualisation: they build a customised solution for one (the first) client; charge them the full cost of development despite the fact that this client has invested a significant amount of time co-developing and testing the solution (and has probably been the victim of lots of v1 bugs); and then re-sell it to other clients with a fat profit margin. This has been a very profitable modus operandi across the technology sector for as long as I can remember.

LOOKING TO THE FUTURE From the outset PeopleWeek designed its technology to be able to offer common solutions with different configurations. We then started offering mutualised solutions several years ago and can also deploy white label solutions. This approach has been an important way for us to develop our suite of software, acquire new clients, and respond to client requests in an affordable way. We see it as a win-win. Looking to the future, we hope that the trend towards mutualisation will continue to grow. This will put healthy pressure on software companies to evolve their modus operandi.