I don't have much experience outside software, but when I think back to the previous successful attempts at buying/bringing in an outside software component or service, they all have something in common: commodity.

On the other hand, I can't think of a single time (both in my experience at current and previous employers) where outsourcing or buying a tailored component or service has resulted in something more successful than if we'd built/done it in-house.

I was giving this a bit of thought on the way into work this morning, especially in light of this quote from Malcolm's blog:

to outsource something you must understand the APIs and contracts between the outsourced and the remaining before you initiate the outsource

When consuming a commodity product, the customer is generally prepared to bend its requirements and approaches to fit that product. The commodity service becomes the authority :- 'this is how it's done', and the contract of service is rigid and easily understood.

However, a tailored service leaves the API/contract and the authority to the customer, which means that it must understand and articulate its own requirements. Unfortunately providing a service or product on adhoc requirements (especially poorly understood ones) requires a high degree of communication between supplier and customer, not to mention common understanding. This is where in-house building does better in my experience - the communication bandwidth is higher and the understanding and motivations are much more closely aligned.

So I would hazard a guess that it is better to buy when the supplier sets the interface (and sticks to it) and the customer is able to understand and adapt to that interface. Usually that means the supplier has already built the product or service and is merely selling it. Letting the client negotiate the interface/terms is much more error-prone and risky, and is rarely successful in my experience (both in terms of cost and return).