At the crossroads of marketing and technology, the question of whether to build functionality or to buy it from a vendor constantly arises. Often the question becomes political and tinged by ego; technology may pushback if requirements seem superfluous or marketing may be skeptical that technology can build the same functionality as an established vendor.
In this post, I’d like to posit a framework that will allow technology and marketing to come together and evaluate new functionality objectively, regardless of internal dynamics.
Sounds great, right? Of course, it is! However, it’s not a fool-proof plan for making the build vs. buy decision; it’s more a push in the right direction to get the entire org on the same page.
In this simplified framework, there are two scales to consider:
Customization – How much custom functionality do we require? How much of the vendor’s out-of-the-box product would need to be changed?
Specialization – How specific is the functionality to a specific type of technology or sector of marketing? How much do we need the vendor’s expertise?
With this in mind, we can plot where build and buy make sense:
Buy: If your functionality requires a high amount of specialization (that you likely do not have internally) and a low amount of customization, go ahead and purchase something as close to out-of-the-box as you can
Build: If the functionality that you want to build is pretty standard technology but requires a lot of customization for your specific org, you should consider building internally
Consult: This one is interesting – if you don’t feel a vendor can meet your customization needs, but you also don’t feel you have the internal chops to build the functionality outright, see if you can pay for consulting hours. I personally have not tried this method out yet, but I think it has legs.
Ignore/Hack: If you need functionality that is neither specific nor custom, evaluate if you really need that functionality at all. If you do, see if you can cheaply hack it together for a while, and focus on the meatier initiatives.
Of course, this framework ignores other important factors like the temporal need for the functionality (how long are we going to use this?) and the internal resources (do we have anyone to work on this?) but it should help set you down the right path.