Selecting off-the-shelf software (or, how to avoid buying a lemon)

Here at Isotoma we often get asked what the differences are between off-the-shelf and bespoke software, and how to decide which is the right approach for a given situation.

Generally software that has been written specifically for you (by companies like us) is referred to as “custom” or “bespoke”, while software that is customised, configured and deployed to many customers is referred to as “boxed”, “off-the-shelf” or “COTS” (Commercial Off-The-Shelf).

Isotoma is a bespoke software development company. This means that we take generic frameworks and build applications tailored to our customers’ needs on top of those frameworks, rather than having a single product of our own that meets a particular need that we resell to our customers (for example a content management system or an ecommerce system).

We’re very upfront in our answer to the “bespoke or off-the-shelf” question; if there’s off-the-shelf software that meets your needs we strongly recommend you go that route. While bespoke software brings huge benefits in the right situation it also has limitations, complexities and costs. You need to be sure that it’s right for you before going down the bespoke road.

Equally you need to be sure that you’re assessing the right things (not just features!) when considering off-the-shelf software for your project. All software investments bring risks to an organisation, and the risks of off-the-shelf can often be subtler and harder to spot, yet equally as impactful, as those of bespoke software.

At its best buying off-the-shelf software can be an extremely cost effective way of getting the features you needs and of future-proofing your software investment. But at its worst it can be a way of tying yourself in to a closed environment that is expensive to customise and hard to migrate away from.

Any off-the-shelf product works best when the requirements it serves are shared by lots of organisations. There the economy of scale means that every customer gets a great product without having to pay for the development of all the features. We wouldn’t ever suggest, for example, building a blogging platform from scratch, nor a word processor or an accounting package. These are all problems shared by countless individuals and organisations around the globe where product companies are easily able to serve everyone’s needs.

However, whenever an organisation’s requirements for the product diverge substantially from the needs of the primary customers problems very rapidly occur, meaning either increased cost, compromised experience or, more often than not, both.

When selecting a product consider how much customisation you will need to make the product really sing for your organisation. And consider how you would be affected if you simply couldn’t have half of those customisations you’re imagining (regardless of whether this was through technical limitations or lack of budget for the necessary changes).

Next it’s important to think about the existing customer base of the product. If the product has thousands of customers, many like you, all successfully using it then you can probably feel comfortable that a) the product really is likely to meet your needs and b) the team behind it are likely to be around and supporting the product for the lifetime of your use of it.

Taking on very niche off-the-shelf products or off-the-shelf products from small suppliers can be extremely risky. The worst case is that under the hood each installation is in fact an alteration of the underlying base product, the “licence fee” being used to cover the cost of the developers implementing the features that the salesman told you already existed. Here you risk expensive maintenance costs, delays in implementation and a high rate of bugs, as you were sold something off-the-shelf (and had assumed the time scales that go with that) yet in fact custom software is being developed on your behalf at cut rates and at double quick time.

You should definitely carefully assess products with very small numbers of installed customers. Unless you are extremely confident that it meets your needs entirely unchanged or you are happy to invest in the development of the product in the long term they should probably be avoided. These are often only products in the sense of “hey, we’ve made this thing for so and so, I bet others like them will need it too.”

Potentially as troublesome is the risk of delays or exorbitant fees if the resources of the team behind the product become stretched. If you need to call upon consultancy or professional services will the team be able to support you in a timely and cost effective manner?

Finally it’s worth considering the impact on your business processes. In general products work well for organisations that are just setting out, as any limitations imposed by a boxed product do not conflict directly with the way the organisation wants to do business. In addition, very young organisations do not entirely understand their requirements and so having a set of predefined features given to them allows them to develop their own business processes alongside those features.

Older organisations tend to struggle with products, particularly at the cheaper (and less customisable) end of the spectrum. They have a clear understanding of their requirements and are looking to create efficiency within their organisation. It is no longer acceptable to have predefined solutions forced upon the business, as it is exactly those predefined solutions that are causing the inefficiencies that the company is trying to drive out. In this case bespoke software has huge advantages, being tailored exactly to the organisation’s understanding of its own needs.

So you must consider the scope and scale of changes to your business processes that the new software will bring. How substantial are they? Are you ready for them? Will your users support you in making them? And can you drive them through at the same time as running a new software project?

With all the above in mind, how do you make sure that an off-the-shelf product will meet your needs and that you’re not investing in a lemon?

Here are some questions worth asking during the selection process. There are no right answers, but by having the conversation with potential vendors at this stage you may flush out some problems that you would otherwise have uncovered much later in the project:

  • How many paying customers do you already have for the version you are selling to me?
  • How many paying customers of our installation size and type do you have?
  • Can I talk to at least 2 of your customers about their experiences of the product and your services?
  • What is the average customisation cost of an implementation?
  • How much do you charge per day/per hour for professional services?
  • What is the average turnaround time for professional services requests?
  • Is there a VAR (Value Added Reseller) or partner network around the product that I can tap into if I need extra help with customisation/integration?
  • Is there an API that I can build on and use to integrate with our other systems? (if yes, can we see the documentation before we sign up?)
  • How easy is it for me to export my data from your product in a way that’s possible to import into an alternative?
  • Can I host the product myself? If so, what are the minimum hardware specifications for an installation of our size and type, and who is responsible for performance issues should they occur?
  • Do you offer a support agreement of any sort? What SLA options do you offer and how much might a support agreement cost?
  • When was the last major version released, and how many customers upgraded (and how many do you still have running the old version)?
  • What was the average upgrade cost when customers moved to this major version?
  • When do you plan to release the next major version?
  • Is there a user group for the product that I can talk to or join?
  • How are new features for future versions decided?
  • Do features I request and pay for get rolled out to other customers in future versions?
  • And perhaps most importantly: what is the roadmap for the product over the next 18 to 24 months?

Of course, there are equally detailed lists of questions you should be asking when selecting a bespoke development partner or when selecting an open source project, but both of those are for another day. Hopefully this list at least helps a little with the decision making process.

About usIsotoma is a bespoke software development company based in York and London specialising in web apps, mobile apps and product design. If you’d like to know more you can review our work or get in touch.