Using 3rd party vendor for for core IP solution

Hey, I have some experience (and some thoughts!)

I tend to recommend keeping core parts of the product in-house and outsourcing non-core parts. But something to consider is whether using a vendors’ solution give you a significant advantage in time-to-market over your competitors by filling a hole in your product? In this case it may be very sensible to use the vendor’s solution to realise this advantage.

There will likely be bugs/issues and features in the vendor solution that don’t quite fit with your product - the question then is how critical these issues are for your users and much influence you have on the vendor. 20 years ago  was in a similar situation and we decided to use the vendor solution - it gave us a good step-up in the market but 4-5 years later the vendor hadn’t fixed some bugs and then discontinued the component we were using - we decided to build our own custom component rrather than looking for another vendor - which was more expensive than using the vendor component but we could build something that fit very well with the rest of our software.

If it is core to your solution, how will you differentiate your product if your competitors also start using it, will it be obvious that your product is better for them?

Depending on the vendor’s model you might also want to check license terms, royalties, restrictions on usage, liabilities etc. if you have not already done so. 

Hope that helps.

I’ll second @markdalgarno’s comment:

But something to consider is whether using a vendors’ solution give you a significant advantage in time-to-market over your competitors by filling a hole in your product?

I’ve gone this route in the past to beat the market. But as Mark also wisely noted, the competition can buy and integrate your cool new competency. So what do you do from there?

When at all possible, make sure your agreement with the 3rd party does not prohibit development of an in-house solution. If the feature is truly core to your solution, you probably don’t want to be locked into the dependency long term.

In a perfect world, you’ll have two dedicated teams:

1. The first team will work on integration of the licensed solution in an isolated and swappable architecture that allows an easy way out.
2. The second will build a custom solution based on learnings from the fast-to-market version that better answers your product’s specific needs. 

As soon as is reasonable, you swap in your fancy new bespoke feature set and part amicably with your early partner.