Price is visible; system cost is distributed

Procurement decisions are often compared in columns: license cost, implementation fee, discount, contract term. Those numbers matter because they are legible.

The less visible costs arrive later: integration work, duplicate data, training, manual reconciliation, support, security review, process changes, admin ownership, reporting, renewal negotiation, and the cost of eventually leaving.

The cheapest option can become expensive because the purchase price belongs to one budget while the operating cost is distributed across everyone else.

Labor is part of the architecture

I have seen tools justified because they reduced a software line item while quietly requiring people to become the integration layer. A person exports data. Another cleans it. Someone reconciles definitions. A manager explains why two dashboards disagree.

None of those hours appear on the vendor invoice. They are still part of the cost.

Technology portfolios rarely fail because one tool is catastrophically bad. They become expensive through accumulation. Another field. Another integration. Another workflow. Another exception. Another source of truth that is almost the same as the previous one.

At one organization, simply baselining Salesforce meant confronting hundreds of objects and more than ten thousand fields. The number itself was not the diagnosis. It was evidence of years of decisions accumulating faster than the system’s ability to retire them.

Total cost includes the exit

I also want to know what happens when the relationship ends. Can we export our data cleanly? Who owns the configuration? How much process has been shaped around proprietary behavior? What knowledge exists only with the vendor?

A low entry price paired with a punishing exit is not a cheap system. It is deferred cost.

Instead of asking only ‘What does this cost?’ I prefer ‘What does this decision require the rest of the system to become?’

That question includes money, but also people, process, data, attention, governance, and future flexibility. It turns procurement into architecture.

A price tells you what you pay to acquire something. A system tells you what you will keep paying to make it work.

Stewardship is part of procurement

Systems, to me, are also about sharing resources—the financial, legal, human, and technical. That makes procurement a stewardship decision, not merely a purchasing decision.

A simplified technology stack can be more secure and can make quality data easier to share, but simplification is not automatically virtuous either. The question is what the tool requires from the surrounding system and whether that requirement is worth the capability it creates.

The cheapest license can be expensive if people become middleware. The expensive platform can be waste if no one can use the capability it was bought to provide. Price is one resource signal among many.

The expensive part is often coordination

A tool can be inexpensive and still create expensive relationships between teams. Finance reconciles it. Security reviews it. Operations administers it. Data engineering moves information in and out. Managers explain discrepancies. Users invent workarounds. Each cost may be reasonable in isolation while the combined system is not.

This is one reason I prefer portfolio decisions to isolated purchasing decisions. The question is not only whether a product is worth its price. It is what adding it asks the rest of the environment to become.