How to Choose Between Building Versus Buying

The choice of building or buying software is a choice that comes up very often and is often seen in a superficial way. This is also a problem for which we do not really know where to start. In this article, I propose a simple and well-framed decision support framework to help you reflect on this subject.

It consists of four axes of analysis, which will give you the inputs to then be able to come out with two comparative business plans, with the major risks and advantages that you may experience in choosing one over the other.

Strategy Needs

You need first to define your operational strategy goals and tactic. What are your objectives? How would you like to achieve them? It's up to you to answer to this question, but the key points to address are the need to make the application evolve a lot, and if your application is strategic or not for your business. If you won't need to evolve it, and that your application is not strategic, then buy. Otherwise it would be better to build.

You then need to know the general market/reference tool capacity. Does a tool do the same thing that you want to do in another company? If yes, maybe buy. But let's have a look into other topics.

Functionalities Needs

Are there complex functionalities to implement or not? The functionalities to be implemented can be complex to define and implement. Do you want to define everything yourself? Do you want a lot of specific features or not? Do you think your needs are unique?

To put it simply, if it is complex and not specific, then clearly buy. Otherwise, it's not enough to say build.

The other question is to ask is whether this represents a differentiating activity for you. A core activity? If you answer yes to both questions, it starts to tip in favor of building. But that's not all.

Operational Needs

Will the application constantly need to evolve functionally or technically because you will have more and more users in the future? If so, we lean towards building. If not at all that, then buy.

Short-term (buy) and long-term (build) needs. If you have to finish next week, you can stop everything and buy. If you have lots of money and time, then build and have fun!

You will need to train users on your tool. Will you have the means to do it yourself or will you have to go through an outside company? This is not necessarily a strong argument, but it deserves to be asked, because if you buy it will be easier to train people at the end.

Technical Needs

 Will you need Java developers or Catia developers? And which one is easier to find? If your choice is not easy to find developers, you'll have issues in making evolutions on your application. And it will drive your ability to follow the project over the very long term.

If you have a lot of trouble getting developers, we go as far as possible to the buy. Otherwise, the build is not excluded

You should also explore the need/desire for publisher support? Keep in mind that some publishers won't help you a lot to develop on their tools. 

And then the last sub-topic: internal stack adhesion. If your IT is full web service, and the tool we present only supports files at D+1, I guess this application will be able to go to the garbage directly.

The Final Word

You have to make your business plan comparative over several years between buy and build. For me, it is the justice of the peace, even if it has to be weighed against the points raised in the other areas of study. The compared business plans must be aligned with your strategy, and ideally chosen according to the long-term price.