One of the weird things about software selection is how quickly it can turn into an identity. Some people are vendor people. Some are open-source people. Build versus buy becomes a philosophical position instead of a decision about a particular problem. I have a bias here too. My instincts lean toward building. Part of that probably comes from an extreme-ownership mindset. If a system matters, I like the idea of understanding it, shaping it, and owning the outcome rather than assuming somebody else will make it work for us.
A recent software decision forced me to test this instinct. We had a real use for the capability, and I could imagine a path where we built or assembled more of it ourselves. I was not aware of a single alternative that gave us everything we wanted without combining multiple pieces, but that alone would not have ruled it out. The hard problem was the work behind the choice.
The people who needed the capability were not a software product team. Their primary responsibility was operating the environment the new capability was supposed to improve. Choosing to build would not simply have meant avoiding a purchase. It would have meant deciding that this team, or another team somewhere in the organization, should take on substantially more software engineering work. That needed people, time, and enough software-development expertise to create something we could trust in production and continue supporting after building it was over.
The organization could have invested in that. We could have hired differently, shifted priorities, created stronger alignment, and committed to a longer timeline. Another internal development team could theoretically have helped. But those choices have consequences too. Moving development capacity away from existing priorities to build an internal platform is still an allocation decision. Asking an operational team to become a software product team is one too.
In this case, buying the product got us to the capability faster without asking the organization to create an entirely new competency around it. That didn’t mean we outsourced ownership. The product still had to be installed. Someone still had to own it, monitor it, maintain it, upgrade it, understand how it behaved, help the user community, and make sure it remains useful. Buying changed the work we were accepting. It did not make the work disappear.
I think this is the part that gets lost when software decisions become arguments about vendors and open source. Open source is not synonymous with building everything yourself. A commercial product is not synonymous with handing every responsibility to a vendor. There are many ways to consume and support software on either side. The better question for me is what work the organization is choosing to own.
With the new software, the build path would have moved more responsibility toward software development, integration, testing, lifecycle management, and long-term platform ownership. The purchase still created an operating responsibility, but it kept more of that responsibility inside a shape the team could realistically support. That was the trade-off we were actually making, not whether one software philosophy was better than another.
There is a danger in taking supportability too far. An organization’s current capabilities are real constraints, but they are not immutable ones. “We don’t have the people to support that” may be a perfectly good reason not to choose something today. It becomes a weaker argument when the capability would create enough value to justify hiring, training, or changing how the team operates.
If building had created enough advantage, and the organization had been willing to provide the alignment, staffing, and timeline to sustain it, I could have reached a different conclusion.
The same is true of support. Organizations often want someone they can hold accountable. “Get the vendor on the phone” is a very real operating model, and there is value in having an escalation path when something important breaks. That does not make vendor support magical, and it does not make software without a traditional vendor irresponsible. It means the organization needs to be explicit about where expertise and accountability will come from.
If there is no vendor to call, the organization has accepted more responsibility for understanding, diagnosing, and sustaining that software itself. Sometimes that is exactly the right trade. Sometimes it is not. What matters is being deliberate about it rather than treating the absence or presence of a vendor as evidence that the choice is inherently better.
For the new software, we bought. I still like the idea of building, and I still think organizations should develop new capabilities when those capabilities matter. But wanting more ownership is different from pretending the capacity to exercise that ownership already exists.
Buying software is still an engineering decision because the purchase does not end the engineering. It defines which engineering work comes next.