For years, enterprise software conversations have revolved around a familiar debate.

Should we build? Or should we buy?

Should we invest in a custom platform tailored to our business? Or should we adopt an off-the-shelf solution like Salesforce, HubSpot, SAP, or any of the hundreds of products already available in the market?

Entire industries have been built around helping companies answer that question. Consultants analyze it. Architects debate it. Technology leaders defend it. Software vendors profit from it.

But lately I've been wondering whether we're all debating the wrong thing.

Because before we ask whether something should be built or bought, shouldn't we first ask whether it needs to be different at all?

The software industry has spent decades reinforcing the belief that every company is unique. And to be fair, every company does have its own identity. Its own culture. Its own leadership style. Its own ambitions.

But when we move away from identity and look at operations, the picture becomes far less unique.

Take sales as an example. Every sales team in the world exists to achieve the same outcome: generate revenue. The product may change. The pricing may change. The market may change. But the objective remains remarkably consistent.

Find prospects. Build trust. Create opportunities. Close deals.

What differs is usually the path taken to get there. One company discounts aggressively. Another protects margins. A third relies heavily on relationships. These are different approaches. But are they truly unique enough to justify entirely different software ecosystems?

That's where I think things become interesting.

Many organizations have confused process variation with competitive advantage. They're not the same thing.

Just because a company executes a process differently doesn't automatically mean the process itself is unique. And yet an enormous amount of software spending is driven by exactly that assumption.

I've seen organizations convince themselves that their workflow is unlike anything else in the market. That generic software can't support them. That custom software is the only answer. Sometimes they're right. Often they're not.

What's fascinating is that the software industry has built an entire economy around this belief. An economy that depends on organizations seeing themselves as operationally unique.

But what if the future moves in the opposite direction?

What if governments begin standardizing more of the processes that move money? Imagine a world where invoicing follows a common framework. Payment reconciliation follows a common framework. Compliance reporting follows a common framework. Procurement follows a common framework. Financial auditing follows a common framework.

Not because software vendors agreed to it. But because regulators demanded it.

The moment that happens, the build-versus-buy discussion becomes significantly less important. Because the process itself is no longer the differentiator. The process becomes a commodity.

And once that happens, software starts behaving differently. Organizations stop competing through workflow mechanics. They stop competing through administrative complexity. They stop competing through internal process customization.

Instead, they compete through decisions. Customer experience. Relationships. Execution quality. Speed of adaptation. Intelligence. The things customers actually notice.

Before anyone interprets this as an argument for buying Salesforce, HubSpot, SAP, or any other major platform — that's not the point. Those platforms come with their own risks. Vendor lock-in is real. Recurring subscription costs are real. Migration pain is real. In some situations, those risks can become more dangerous than building custom software itself.

This isn't a SaaS argument. It's a standardization argument.

Because if the underlying process eventually becomes standardized, then neither the software vendor nor the custom-built platform becomes the most important question.

The real question becomes: why are we spending so much time differentiating systems that support identical outcomes?

Maybe the future of software isn't about building increasingly custom platforms for increasingly similar businesses. Maybe it's about recognizing which parts of a business deserve differentiation and which parts don't.

Because not every workflow is a competitive advantage. Not every process is unique.

And if regulation eventually standardizes the movement of value across industries, the companies that win won't be the ones that built the most software. They'll be the ones that figured out where uniqueness actually matters.