It is one of the decisions that moves the most money and one of the ones taken with the least rigour. It usually gets decided by inertia: you buy because there is budget and a deadline, or you build because there is an internal team that fancies building it. Neither is a reason.
The short rule
Buy what is the same for everybody. Build what makes you different. And compose when you need something specific on top of something standard.
It sounds obvious until you apply it to your own list and discover you are developing a document manager in-house — which is exactly the same in your company as in any other — while buying a generic tool for the part of the process where your margin is actually decided.
Three questions before deciding
- Does this differentiate us? If a competitor with the same tool would get the same result, it does not differentiate you. Buy it.
- Does it depend on data only we have? Your history, your case files, your accumulated know-how. If the answer is yes, there is something worth building there, because it improves with use and nobody can copy it.
- How many integrations does it need? If it has to talk to four of your systems, the expensive part is never the model. It is the glue. And you are the one who will maintain that glue.
Composing, the forgotten option
Between buying and building there is a large space almost nobody considers: taking standard pieces and building the layer that knows your business on top. The database, the model and the infrastructure belong to somebody else. The logic of your process, your rules and your knowledge are yours.
That is usually where the best ratio of cost to control sits. You build little, but you build what matters. And if a better or cheaper model appears tomorrow, you swap that piece without rebuilding anything else.
The cost nobody writes down
Every decision to buy carries a cost that does not appear on the quote: what you will stop learning. If the whole process lives inside a closed tool, the data about how your operation works stays in there. In two years you will want to use it to improve, and you will find you cannot export it in any useful form.
Buy the generic. Build what only you can build. And always keep your data.
A note about us
We build software and we also recommend not building it. We are not a partner of any vendor, so nobody pays us a commission for placing a licence, and we do not charge more for doing a development than for telling you the development is unnecessary. It sounds like a small thing, but it is what makes the recommendation credible.
When we do build, we hand over the code, the data and the documentation. If you want to carry on with another team tomorrow, you can.