Build vs. Buy


IT departments are always facing the decision whether to build or buy a new application.  Sometimes the answer is easy.  For example, you would never build your own word processor or spreadsheet program.  Similarly, you would probably never buy an off-the-shelf application to control the rockets on your space shuttle (What? You don’t have one yet?).  However between these two extremes is a lot of grey area that have created great debates around the coffee machine of many companies between the business managers who think that buying software is cheaper and the IT managers who believe that building software can provide more feature flexibility and better support.  But who is right?

First, I cannot absolutely tell you what to do in your current situation.  If I could predict the future, I would have bought a couple of winning lottery tickets years ago. However, perhaps we can look at some of the pros and cons of both sides of the argument.

Buying software can be cheaper, but only as much as the application is a commodity.  That is why people buy their word processing and spreadsheet applications.  There is no way to justify the salary of a programmer and the time it will take to developing a reliable word processor or spreadsheet program.  On the other hand, companies like Microsoft who sell word processors and spreadsheets can afford to sell these products for such a low price.  How?  Because they expect to sell millions of copies and can spread the development costs over all those copies.  Also these programs are commodities in that everyone uses them in pretty much the same way so there is no need to customize the software for different industries much less for individual clients.  What customization is needed by 99% of the users is already built into the product through settings and features.

Buying software is also faster because in most cases the software already exists and all you have to do is pay for it and install it.  These days, you don’t even have to go to a store.  You can just download it from the Internet.  If your need is immediate, you might not be able to wait for someone to design the application, program it, test it, and provide a production version for you to use, so buying a product is the answer. 

On the other hand, the feature set for purchased software is usually fixed.  You cannot go to the vendor in most cases and ask for a custom version of the software just for your organization.  Imagine going to Microsoft to ask for a custom version of Microsoft Project to handle project planning the way your company wants to.  Of course, the more popular the software is, the more features it generally has and you can often customize the application to work well enough to satisfy your needs.  For less popular software, your choices are more limited.  If you want to use the software, you need to adapt your processes to work with the software rather than to adapt the software to work with your processes.

Then there is the support issue.  When you buy software, you may or may not get support.  Sometimes you can buy support contracts that allow you a fixed number of support calls per year.  Sometimes that support consists of a help desk in some foreign country where quite frankly you have trouble communicating with their representatives (Like people from the deep south or New England.  What were you thinking?).   Finally, some products don’t provide any real support.  And if you need a major change to the software to fit your business processes, you are usually out of luck or they may be willing to create a custom version of the application for you, but at a cost of time and materials.  Even if you do get support and even if they are willing to modify the application for you, it may be on their time schedule and not yours.  If your production line is down while you wait for bug fixes or program changes that you need, the cost of lost production and subsequent sales can climb very high.

Another problem with buying software or even with hiring a consultant to write your software is the question of whether they will be around when you need them.  Many private consultants (not all) may just be doing consulting until they get a full time gig.  Then if you did not negotiate to get the source code and system documentation, you are left holding a quickly aging and brain-dead piece of software with no idea what makes it work.  Even if you do get the source code, can your programming staff, if you have one, get into the head of the original developer to figure out what he or she was thinking?

This brings up a side issue.  Even if you have a programming team in-house, if you buy most of your software or hire consultants to write it, you in-house team will quickly lose its edge in terms of developing new applications and even in maintaining the existing ones.  Programming is very much a use it or lose it skill.  Also your best programmers will not hang around if you give all of the cool development projects to outside consultants and leave the maintenance to your internal staff.  No one wants to be the foster parent of orphaned applications.

On the other hand, when you develop an application in-house, you can control the features that the application has.  You foster the development of in-house skills that will assist you in supporting changes to the application and fixing of the inevitable bugs.  Most importantly, you can get exactly what you need and want in the application.   If the application fails or if you need major changes, you own the development team who wrote the application and can control their priorities to get the changes done as quickly as possible.  And since your team wrote the application, they will feel more ownership in getting it fixed and working perfectly.

These few points in favor of in-house may not sound impressive against the advantages of purchased software if you are a business manager, at least not until you find yourself facing a very specific need or a need that frequently changes over time.  Sure you might think you can save money buying a product that meets most of your needs.  However, the cost of customizing that software can quickly surpass the savings of building the application from scratch.  Why?  I’ve seen cases where the purchased software is written in obsolete languages or tools that are several versions out of date and no one on your staff has a clue how to make changes to it.  The only solution then is to totally rewrite the software.  You have already spent time and money on the first version you bought and now need to make a second investment in redoing what you could have done in the first place.

I don’t think there is an absolute way to calculate which path is better when you need a new application.  The decision is often as political as it is technical.  A lot too may also depend on how much development you need over time.  If your needs are high, I would recommend building a good agile development team.  If your needs are rare, perhaps developing a relationship with a good local consulting group (not an individual) who you can hire as needed and who has been around for several years may be a good choice.  But I do not think you will be successful if you relegate your in-house development team to a maintenance role fixing other people’s software who took the money and ran.

See you next time.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s