• Why should a company invest in a Commercial Off the shelf (COTS) product?
  • Is it the cost of in-house development, support or are there other reasons to not buy an COTS product?

By Commercial Off the shelf (COTS) products I mean products such as SharePoint, SAP, MS Dynamics. Not Word/Excel/Outlook.

By company I refer to a large enterprise.

  • 3
    I assume you're talking about what is more commonly called a "shrinkwrap" product around here. It would depend on what sorts of products you were talking about. Word processing? Accounting? HR? Robotics? Commented Jan 19, 2011 at 19:00
  • @David I update the question. Commented Jan 19, 2011 at 19:04
  • What in the world is an "Out of the Box" product? I saw your examples, but I do not get what the difference is between those that are and those that are not.
    – Job
    Commented Jan 19, 2011 at 20:08
  • 2
    @Amir, if anything, then MS Office is what is really ready to be used out of the box. Sharepoint server needs a lot of configuration. I still do not understand why those big MSFT products deserve their big name.
    – Job
    Commented Jan 19, 2011 at 20:21
  • 4
    I'm not familiar with SAP, but SAP programmers get big money customizing it. My wife works with PeopleSoft (now run by Oracle). What you're referring to as COTS is what some other people call consultingware. Commented Jan 19, 2011 at 22:52

7 Answers 7


I have to add to the cons, COTS (Commercial off-the-shelf) products are often designed badly and perform worse. They are designed to sell features such as flexibility but generally in my experience they use the database incorrectly (often due to sticking to ANSI SQL rather than faster performing database-specific SQL because they could have any number of database backends and generally having a database design that shows they had no one with database expertise on their design team) and are performance hogs.

The flexibility (that is almost never used much as it is usually so difficult to actually do and often requires you to pay very expensive company contractors to be able to see the added fields in reports, etc.) usually comes with a huge price tag in performance, awkward design and general dislike. These products almost never take the time to properly define the requirements (relying instead on their problematic "flexibility") and thus you get project management software that doesn't even have a field for clients (what company is big enough to need project management software that costs over 100K doesn't have internal and external clients that you need to be able to filter on?) and other such nonsense.

The last COTS product we bought was so bad that our developers offered to fix our old company-designed product on their own time to give it what they thought they were getting (but actually didn't get) in this very expensive PM software we bought. 100% of the users of this system hated it because of the bad design and worse performance. It did not provide anyone in the company with what they needed in terms of reports or documentation and we could not get rid of this piece of trash because we had spent too much money on it. We now have less documentation of our development process and what we do put in the system takes devs longer to actually put in and takes managers exponentially more time to manage.

Another COTS product it was my misfortune to support caused the call takers at a call center to have to wait minutes to go to the next screen while talking to the already irate customers (we handled product complaints). Timeouts were so frequent we weren't even supposed to report them anymore to the help desk.

Another COTS product was created by a French company and while it seemed to work ok, writing custom reports was a real fun job since the database schema was in French even though the user screens were in English.

Then there was the horrible HR COTS product to do timesheets with that we couldn't even get the people entering the original data to figure out how to change a supervisor when the person moved to a new boss or the old one left. Kind of hard to get my leave approved when the person who was two supervisors previous to my current one and who left the company over a year ago is my approver and no one can figure out how to fix that. And the equally bad performance review software that lost the mid-year reviews and that wouldn't print a version where you could see your rating on each item next to your boss's rating (who would want to see both?) and which didn't actually give enough space to list your accomplishments for the year (why ask me what they were if I can't list them?). Of course, those HR products were so badly designed our web developers were laughing at them when we were trained on how to use them.

I have almost never used a COTS product in an Enterprise organization that worked well or did the job it was supposed to do according to its marketing. And I've seen a lot of these products through the years. The exception would be Red-Gate's products (great products and stellar support and no I don't work for them) and a few small specialized tools, but never a big enterprise-type thing.

Reinventing the wheel (writing your own version rather than using one of these products) is fine when the wheel is misshapen and wobbly to begin with.

Do not buy one of these products without a trial period. You can't tell what they are like to work with until your actual users try to use them.


If it is not core to your business, buy it. You don't design and make your own computers, you buy them. Only use your development resources on something that will make you money. A company makes a COTS product because that is their core expertise. Most likely, it's not your core expertise and you will make something that is of lesser quality AND more expensive.

The only exception would be if there is a need for something that doesn't exist. If you then undertake to create it, do so with the idea that if it is useful to you, it might be useful to someone else. Productize it!

  • 3
    +1 for "You don't design and make your own computers, you buy them." That's a great way of putting it.
    – Ryan Hayes
    Commented Jan 19, 2011 at 20:30
  • 1
    Same goes for light bulbs, pencils, toilet paper, etc, etc...
    – Erik
    Commented Jan 19, 2011 at 20:33


  • Cost of development is generally lower. (If the product is used by many people, then the company making the product can likely afford many more developers and can crank out many more features that are more well tested than you could with your own development team for the same price)
  • Cost of support and maintenence is generally less
  • With new releases of the COTS product, you can "automatically" give your users new features without much work (you still pay for it, of course, but the cost is spread out over all the COTS product's purchasers.
  • Other users besides you are using the product, and giving feedback. This generally results in a more solid product.

If you want to read a peer-reviewed/academic article on the subject, try here.

  • 3
    I would add that the product is not in your core capabilities then shrink-wrap is the way to go. Wasting development dollars on something that can be purchased is just that a waste.
    – Jeff
    Commented Jan 19, 2011 at 19:38
  • @Jeff: Very true. I hate it when I have to write software, that when I count up the hours*$/hr that it becomes DRASTICALLY more expensive than just buying some 3rd party product.
    – Ryan Hayes
    Commented Jan 19, 2011 at 20:08


  • With COTS products, you may be paying for features that you will never use.
  • COTS applications may not provide all of the features that you need and could still require custom 'plugin' development.
  • Integration of COTS applications with existing applications could be difficult and expensive. Integration may also require specialized (wich usually translates to expensive) developers.
  • COTS support may be limited and could get expensive for large companies (or complex installations). Some companies opt for in-house support but this could still require special training.
  • Most COTS application are built for the greater public. This means that applications will generally require configuration before placing it into production. Depending on the complexity, configuation could be expensive if contractors are required.

Before undertaking any project, companies should first see if there are any COTS products that will fulfill the requirements. Both the pros and cons should be weighed before choosing in-house development or a custom off the shelf (COTS) purchase.


When corporations need to solve a problem, they start with the obvious "build vs. buy" decision. Sometimes it is worth it to build a solution, and many times a hybrid solution is called for. Rarely will a large corporation build a major piece of software from scratch--unless it is their core business.

This implies that purchasing COTS is a lot more than the dollar figure for the licenses. It's not unheard of to purchase something expensive like SAP, and spend an additional $25,000 USD to customise it because it performs a critical business need. Developing a system to the same level of stability and transaction assurance will likely dwarf the cost of purchasing the ready made solution and customising it.


When making a build vs buy decision one thing to consider is do you have the talent in-house?

Consider a statistics package for example. A package like SPSS or SAS has been developed over many years, used by many clients and designed and verified by multiple PhD Statisticians.

If your company needs a statistics package, do you have PhD statisticians on staff to verify the accuracy of the calculations you program?


Based on experience, especially with a platform such as ERP, that companies use to run their business, it is quick for Management to go for the COTS ERP platform rather than actually look at what is already working, currently in use or look at other open source platforms that have a large support structure and following. I hate to name products here but if anyone who knows ERP platforms, knows which ERP product I am talking about.

I see top down implementations and decisions being made, where the users are told that the purchase was a management decision, that everyone will have to work with it and that the company already invested too much in it. Have you ever heard of Black Swans?

Big commercial ERP's are presented as flexible and modifiable to your business process. You are given the usual 6 month time frame for implementation and a year later you are still in deployment mode. Users are hating it, it recreates work flows and departments have to spend tons of time and money re-training users on the new work flows. When it is not in place within six months, more money is thrown at it and more contractors are hired to work on issues that should have been identified if they took the bottom up approach.

Listen to your users, adapt current work flows to your ERP modules instead of just saying that is how "ERP" works. Forbid any changes are required to be made on the module, it usually means more money and time. They always give you the same old answer.

I work in a support group and our focus is our customers. We have SLA's we have to meet and the last thing we need is a support platform that creates more problems than the actual support issue. Everything should be designed to ensure that we meet our SLA's but the shift then becomes that the company becomes internally focused as opposed to external, watching for our customers needs. Support staff spend way too much time making sure that each work order or ticket is filled out a specific way rather than actually having a tool for documenting how the issue of the client was received, troubleshot and resolved.

So, if asked whether I prefer COTS to in house? I would maybe select COTS products with good user feedback but really think about it if it were to run my whole business. Both have pros and cons like support, flexibility, system integration, upgrades and patches, and other system growth development.

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