Build vs. Buy – Handling the “We could build it ourselves...” Objection

Here are two approaches I've used very successfully (and seen used very successfully) in battling "build vs. buy" situations:

1. People love to write new code, but hate to QA, support and maintain code already written. You can drive this point home by outlining the customer support calls (and hours) required to help customers (internal or external) use the application; and by the pain and suffering of keeping applications current with the ever-changing versions of Windows, Java, IE, Oracle, etc.etc.etc. and doing the ongoing testing to confirm (yuck). The hours of doing this "not fun" work can help tip the balance to a vision of "using the framework provided by the vendor to create the really interesting stuff internally, and outsource the ugly maintenance and support stuff to the vendor...".

2. Paint a REALLY big picture of "typical" requirements... You can point out, for example, that there are “ten years of development” in your application(s), done (most likely) by dozens of developers and QA folks. The list of features and functions in your offering(s) is likely REALLY long, particularly for comparatively mature products. List the features and functions in their full (gory) length (could be pages of features) and comment that "this list is only those functions required by customers - you should see the ongoing wish-list as well!". The idea here is to make the development project appear to be WAY too large to contemplate for a customer’s small team of developers...