Currently one of the major applications that our organisation produces would be regarded as bespoke software as it is specifically designed for one specific client organisation.

However, we have specifically retained the intellectual capital on the project and a number of different organisations in different countries (with different languages and character sets) now look like they want to purchase our software solution. Our current approach to development passes 9 ½ out of the Joel Test and is improving. However, our approach is all about satisfying the requirements of one specific client and responding quickly to their needs (regardless of whether something is a bug or a change request).

If we want to transition to producing more of an 'Off the Shelf' approach with multiple client organisations---rather than just one client organisation---on a common code base, what are the major differences and what pitfalls do we need to be aware of to successfully make the transition?

3 Answers 3


Some signficant organizational and architectural changes should be enacted to be successful at developing a common product that meets all of your clients specific needs.

Organizationally you will need to change from directly delivering requests of clients to a situation where the development team delivers requests to a product owner within the company. Once you do this, the development team is not working for the clients of the company anymore, the only client that should matter to the development team is the product owner in YOUR company.

The product owner will have to gather requirements from the mutliple clients and determine a common set of requirements that will make the majority of them happy. The development team only needs to worry about making the product owner happy.

Architecturally it helps when designing a product that has a wide array of customer needs to make it as configurable, extensible, decoupled, scalable and componentized as logically possible.

Some good approaches to doing this would be to take the many different pools of requirements and find out what pieces are common amongst all of them. These common requirements will constitute the core of your featureset. Everything that is slightly different than the core can be determined as a configurable feature, setting, or perhaps a whole unique feature that is seperate from the core. Make these seperate features as componentized as possible and spec it out well.

Your customers may look at different features that are currently disabled for their installation of a product and may realize that they might actually want that feature too.

Finally, try to be a "Defensive Designer" without violating the YAGNI principle. This can be a fine line to traverse, but it is a very real possibility that certain architectural and design assumptions can cause you to develop yourself into a corner, causing the need for major refactoring in a future release. Assumptions are CRITICALLY important and should be closely detailed and scrutinized in your technical specifications. An incorrect assumption can cost you dearly later. A good way would be, "I know that the customers are pretty certain that they would like this component to work this specific way, but just in case, I am leaving the option open that this COULD change in the future without causing the need for a major revamp." Sometimes this is as simple as proper componentization and decoupling, other times it borders on possibly developing features that were not requested. You have to make that judgement call for your situation.

  • 1
    This is absolutely correct, the key role in transitioning from contract-coding to product-development is the Product Manager/Owner. When hiring this person (and it probably will be an outside hire, not an internal transfer), be just as serious about it as you would about hiring an architect or senior developer. Getting the wrong person will doom your company and you may not know it until the cash runs out and the doors are padlocked. Dec 23, 2011 at 13:09
  • @RossPatterson It doesn't have to be an outside hire though, but I understand how that helps. Internal management tends to get comfortable with a particular way of doing things and tend to revert back to old habits when the new direction hits some bumps. A good PO should have strong business knowledge and be in tune with their clients as well, and for a niche industry or niche market or a relatively small set of important and unique clients, finding somebody from outside the company that already has this detailed industry knowledge can be difficult. There are pros and cons to each approach.
    – maple_shaft
    Dec 23, 2011 at 13:45

Since you'll have multiple clients, your build/test/deploy process will need to be more robust. If you already have strong engineering practices, then this should be doable, though it still will be a transition. But that's the easy part...

With only one client now, the customer-facing part of your business is straightforward. However with many clients, you'll need to be able to handle all of them independently. You'll need a help desk, possibly a public issue tracker, etc. (There is a reason big companies have "support" engineers on staff; this is a full-time job.)

On the business side, you'll need to ramp-up your sales and marketing. You'll need to cultivate new sales leads and track the satisfaction of existing customers. So if you want to grow big enough, this may mean using CRM or other automated solutions. You'll also have to "get the word out" about your product, which can happen through PR, advertising, tech conferences, etc.

So your process for building the product will need to become more "professional", yes. But it's selling the product that will be the hard part. Good luck!

  • From the perspective of our organisation I think the selling bit is not so difficult (at the moment). We have solved a bit of a niche problem in a user friendly manner and lots of people in the sector we work in have come to us wanting our solution. We need to be able to sell that solution in a packaged manner rather than custom developing the whole thing each time (with multiple code bases to support).
    – AlexC
    Dec 21, 2011 at 9:25

One of the biggest issues you have to deal with is customization. Since you may no longer be responding to individual requests but rather making changes to a product that serves many, you need to decide how to handle the need for some of your clients (especially your intial client who is used to requesting custom solutions) for custom information.

You will also need to learn to filter requests for changes based on what the product needs vice what one company needs.

There are several routes to take in regard to customization and you need to decide which one:

  • Allow no customization - will lose some customers maybe even your bread and butter first customer
  • Create an EAV table in the relational database to allow for lots of customization -flexible but slow and hard to query
  • Create a few undefined columns in key tables to allow for limited customization - can work if you have already designed the 95% that is really needed
  • Use a no sql database for customized information - fine for things that don't need transactional integrity
  • Create separate instances per customer and charge an arm and a leg for customization (especially for custom reporting) - can be very expensive and hard to manage
  • Treat all customization requests as something that all customers will get or be offered as an add on (modularly develop the customization so people can pick and choose what features they want) - may be able to handle most development this way depending on how your current software is structured and what it does.

You need to really think through these issues as customization done wrong can make your software unbelievably slow or can result in the need to for many more programmers than no customization. You may also consider using several of these techniques. All have pluses and minuses.

  • At my last job we were starting a new product and we had several large clients we had custom spinoffs for of the previous version of the product. We took the modular approach with this in mind and while I didn't see it to release it looked like a great fit on paper once we sort of nailed down the granularity of the plugin modules.
    – Rig
    Dec 20, 2011 at 17:28

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.