Buy, Build, or Integrate
The decision is usually made on the wrong axis — cost to first version — when the axis that determines the outcome is who maintains it in year four.
Every industrial technology decision eventually reduces to the same three options. Buy a product that does most of it. Build something that does exactly it. Integrate several existing pieces into something that does most of it and is yours. The choice is usually argued on the cost and time to a working first version, which is the one axis on which building looks competitive and is also the axis that matters least. What determines the outcome, nearly always, is who is responsible for the thing in year four.
The honest case for buying is not that it is cheaper. It is that the vendor's engineering organisation continues to exist. Someone else writes the driver when the controller vendor changes its firmware, patches the library when a vulnerability appears, tests against the new operating system, and answers the phone at two in the morning. You are renting an ongoing capability, not purchasing a capability once. The costs are real and specific: you inherit the product's model of the world, which will not quite match yours; you inherit its release cadence and its end-of-life decisions; you may inherit a licensing structure that punishes exactly the growth you are hoping for; and you will discover that the last fifteen percent of your requirement is either unavailable or available as a custom development at a price that reopens the whole question.
The honest case for building is narrower than it feels and it is not about money. It is appropriate when the thing being built is genuinely differentiating — when it encodes something about your process, your product or your customer relationship that is a real advantage — or when nothing on the market fits and integration would cost more than construction. Both of those happen. What also happens, far more often, is that a team builds because building is more interesting than evaluating, because the first prototype took a fortnight and looked like proof, or because a single capable engineer made it possible. That engineer is the risk. A system that one person understands is an asset until that person changes role, at which point it becomes a liability that nobody can modify and nobody dares replace.
Integration is the middle path and the one most industrial organisations actually end up in, sensibly. A broker, a historian, a visualisation layer, a device management service and some glue is a legitimate architecture, and it lets each piece be replaced independently. Its failure mode is specific: the glue is nobody's product. Interfaces between components are where the version skew, the undocumented assumptions and the silent data loss live, and they are exactly the part that has no vendor and no owner. Integration works when the glue is treated as a real piece of software — with a repository, tests, a named owner and a deployment process — and fails when it is treated as configuration.
A few questions separate these cases faster than a feature comparison. What is the total lifetime, and how does that compare with the expected life of the vendors involved? Who will change this in three years, and do they exist yet? What happens if the vendor doubles the price, is acquired, or discontinues the line — is there an export path for the data, and have you tested it rather than been promised it? Is the requirement stable, or is it the kind that will be revised every quarter, which strongly favours something you control? And is the thing you are considering building actually your business, or is it plumbing that resembles your business because you are close to it?
Two structural points worth stating plainly. First, the maintenance tail of built software is usually estimated at zero and is in practice a meaningful fraction of the original effort every year, indefinitely — and it is paid in the attention of your most capable people, who are the same people you need for the next project. Second, buying does not eliminate work; it converts construction work into integration, configuration and vendor-management work. Programmes that budget for the licence and not for that conversion are the ones that report a purchased system as a failure.
The reasonable default in industrial settings is: buy the commodity layers, integrate at well-defined interfaces, and build only what is genuinely yours — then write down which is which, because the most expensive version of this decision is the one where nobody remembers having made it.