By Sue Brady
When does it make sense to use corporate IT resources to build a system/software/technology vs buying one off-the-shelf? Many companies struggle with this question. The answer is of course, it depends. There are many business tools that are readily available today: content management systems, CRM systems, accounting tools and the like. If you have an IT department that has coders, developers, and other technical functions, you may be able to create these tools yourself. But the question is, should you?
There are good reasons to build tools yourself, such as: 
- There is no off-the-shelf product that satisfies your needs
- A client has asked for a product that they can own
- It will be cheaper to build it
- The off-the-shelf products won’t be able to keep pace with your level of growth
And equally important, there are bad reasons to build it yourself: 
- You have a big IT team and need to keep them busy
- You don’t trust any of the off-the-shelf products
- You need something a little different from the off-the-shelf choices
- You can charge the client for a totally custom product
- It will be cheaper to build it
There are pros and cons to both options. Buying a product typically means the implementation will be faster and the timelines to do so will be more predictable. Risk is lower because the product has been tested and is more standardized. There might even be a certain level of product support for you to take advantage of. But, you also have to stay one step ahead of product enhancements to know that whatever product you’ve chosen can grow with your changing needs. And you need to make sure you understand the product lifecycle so that when you consider costs, you know down the road what you’ll need in the budget for support/changes/enhancements.
Building gives you a certain amount of control but means that you have to manage costs carefully, avoid things like scope creep and continually set timing expectations. Plus you’ll also need to anticipate and handle new product feature releases that your business might need. Make sure you also set expectations around timing. Marketing folks are impatient, so if building is going to take three times as long as buying, you may get pushback. Be sure you have the budget to support the build.
Some companies like to use a hybrid approach where an off-the-shelf product is used, but modified to meet the business’ needs. This can work, but if a large amount of modifications are needed, you probably won’t be saving money or time in the long run.
I came across this rule-of-thumb advice in a variety of places: When you are looking to automate a business process that can be viewed as a commodity, you should buy. When you’re talking about a core competency/differentiator for your company, you should build. Tweet this.
Do your homework, run a cost/benefit analysis, and be realistic with the stake-holders with whichever option you choose.
Digital Marketing Musings 
Good reminders, particularly at this time of year as folks are looking back and thinking about all the things they’ll be kicking off in January.
I also suggest taking in the view from a higher level. We’d all like to think our businesses are unique snowflakes, but when you see them from the outside it all looks like bunch of snow. Most of the stuff we do, just isn’t that different if we’re honest with ourselves.
When looking at the build/buy decision, one should also consider if your process needs to change. Scoping an IT project that’s built on a bunch of bailing wire and chewing gum (both technology and process) that’s accreted over 10 years means “build” is going to tend to win.
By upgrading to a more standard process, you might find it easier to run a cloud-based solution with a few small tweaks to meet your specific needs.
Finally, I find the bias to “build” tends to ignore opportunity cost. Shouldn’t the people on the team be used as much as possible to interact with the customers? I’ve talked with a few companies that have obvious product flaws that haven’t been fixed, while IT people and engineers are engaged building some in-house tool that, ultimately, will tell them they need to fix the product!
Wise words Mark. I do think there are IT departments who want to ‘make it all themselves’ because 1. they are good at it, and 2. they love doing it. But that doesn’t mean they should.