Buy and Configure vs. Build on a Framework

So the trend seems to be favoring purchasing software over building it. But I think Buy vs. Build is a slippery slope, and more so, should be more clearly named: Buy and Configure vs. Build on a Framework.

In my mind, the difficulty of configuring down a complex piece of software is really just  as difficult as building up a piece of software from pre-built frameworks, plug-ins, and templates.

The intent with Buy is not necessarily to spend money (though I do know people that value software strictly on its price tag), but to follow a basic principle: don’t reinvent the wheel. If someone has already done it,  use that first. The question for me is: when does configuration cost more than building?

Buy or Build Where you spend your time Considerations
Buy the enterprise tool that does everything comparing and contrasting various products, learning how to use the proprietary product you select, and a lot of configuring does more than you want, pay a company for support
Build with pre-built frameworks, plug-ins, and templates understanding your business need, learning how to use general-purpose components, and program what you want does exactly what you want, pay a consultant for support

In my experience, configuring is very expensive. I think about my Java programming days when it felt like half of my time was simply spent figuring out how to configure the fancy and expensive server.

From a learning perspective, I’m all about the build. I would much rather have knowledge about a general-purpose framework than knowledge about a proprietary system. General-purpose knowledge has much longer-term value, and can be re-used over and over and over again.

What do you think?

Tags: ,

One comment

  1. Nice blog entry. It’s a tough call between buy vs. build. Yes, building does help create ‘local’ knowledge base and configuring ‘buy’ software can be a royal pain. Our org, like most orgs, grapple with buy vs. build all the time. One item that you did not mention is SaaS, Software as a Service. In a few instance we have actually success used SaaS…