By Jon W. Hansen, FCIPS | Procurement Insights · November 2026
Practitioners, and end-user clients in general, must be builders before they become buyers!
Practitioners must have a builder’s mindset to start!
This week, Heena Purohit, Director of AI Startups at Microsoft, shared a Boston Consulting Group report with a provocative opening line: build versus buy is no longer the right question for enterprise AI. The better question, she wrote, is what you actually need to own.
The BCG report describes four strategies. Adopt, when a capability is widely available and offers little differentiation. Partner, when you need specialized capabilities but not ownership. Build, when your proprietary data, workflows or expertise create a competitive advantage. Buy, when a scarce capability is strategically critical and ownership creates a lasting advantage. Her takeaway: as AI capabilities become commodities, owning the technology matters less than owning what makes it valuable to your business, meaning your data, your workflows and your domain expertise.
I agree with her conclusion. But I would go further, because the debate itself is the problem.
Build versus buy is the most ridiculous debate in the industry today, because without Phase 0™, most organizations are not in a position to do either. It is like shopping for a car before you are old enough to drive.
You have to do both at the same time
Here is what the debate misses. Building and buying are not alternatives. A practitioner who cannot describe how their own operation actually works, including the workarounds, the informal handoffs, the conflicting incentives and the strands no system records, is not ready to build anything. And they are no more ready to buy, because they cannot tell whether what they are buying fits.
Two years ago, when Sievo hosted a panel on this exact question, I put it this way: with either option, practitioners must step up and take the lead in their own initiative’s success. If practitioners cannot do it for themselves, through the build option, they are not going to fare much better with the buy option.
That is what a builder’s mindset means. It does not mean writing your own software. It means understanding your operation the way a builder has to understand it, before anyone writes a line of code or signs a contract.
We have seen this before: the MAI Basic Four
Some of you will remember the MAI Basic Four. I do not just remember it: I have been in high tech since 1983, and I have direct, firsthand experience with industry-specific applications and the MAI Basic Four. In those early days, businesses from law offices and dental practices to restaurants and retailers built their own software to solve their own problems. The technology was an extension of a better process, built on their own experience and expertise. It was the adjunct to the process, not the definer of it.
Then someone in finance usually had a flash of insight. If the application worked this well for us, it would work for others in our sector, and licensing it would recover what we spent building it. Those businesses became the original solution-provider incubators.
Two things made that model work:
- The builders used the solution on their own business first. If the technology could not improve their own operation, there was no reason to believe it would improve anyone else’s.
- The software fit the way the work was actually done, because the people who did the work built it. That minimized the need for change management, because the system matched how the world operated, and then made it better.
Practitioners were builders first, and buyers second, and the solutions were better for it.
Where it went wrong
Somewhere between the early mainframe era, when customers were expected to write their own software, and the all-encompassing turnkey enterprise suites that followed, the builder’s mindset was lost. The vendor’s optimism, the belief that technology can solve any problem, survived. The practitioner’s understanding of their own operation did not travel with it.
As I wrote in 2010, early failures were contained, usually limited to a desktop or a single application. Enterprise failures were not: Hershey’s and FoxMeyer Drug became the examples everyone cites. Two years earlier, I had pointed to Hewlett-Packard’s troubled supply chain implementation as proof that technical capability does not translate into process efficiency.
The shift to “create once, use many” made software scalable. It did not make human experience and expertise scalable. As I put it to Duncan Jones in 2024, you can give five people the same recipe, and one dish will turn out differently, even better, than the others. The more complex the recipe, the wider the gap. And as Tom Craig observed the same year, finance often turned enterprise ERP into an accounting tool, limiting how much of it was used, and paying for the rest.
Practitioners never stopped building
Here is the irony. Practitioners never stopped building. They just stopped getting credit for it.
I was introduced to VisiCalc, the first spreadsheet, in 1979. More than four decades later, the spreadsheet is still one of the tools supply chain managers rely on most, not because practitioners failed to adopt technology, but because the spreadsheet is where they build what their enterprise systems do not do. In July of this year, I described personal AI as the new shadow spreadsheet: adopted from the bottom up, outside what the enterprise can see.
The builder’s mindset is already there. Most organizations simply treat it as a compliance problem instead of the asset it is.
What the BCG report gets right, and what comes first
Heena’s question, what do you actually need to own, is the right one. Her answer is right too: your data, your workflows and your domain expertise. But notice what all three have in common. None of them can be bought, and none of them can be owned until they are understood.
That understanding is what Phase 0™ establishes. It starts from the outcome the operation is producing now and traces back, through the people, decisions, incentives, workarounds and dependencies that produce it. Only then can an organization decide what to adopt, what to partner for, what to build and what to buy, because only then does it know what problem it is actually trying to solve.
Virginia’s eVA program is the case I have returned to for nearly two decades. In 2007, I wrote that eVA’s leaders avoided the trap of the initiative becoming a software project. They shifted the emphasis from cost justification to process understanding and refinement. The software did the job it was required to do, but eVA’s effectiveness had little to do with the technology and much more to do with the methodology behind it.
Build to understand. Buy to scale.
The AI era is making the MAI Basic Four model possible again. Practitioners can build working tools themselves, quickly, from their own understanding of the work. That is not a threat to the buy decision. It is what makes a good buy decision possible.
Build to understand. Then buy, partner or adopt to scale what you have understood. Never buy what you do not understand, or what you believe you understand but have not investigated.
The winners will not be the organizations that own the most AI, or even the ones that know what not to own. They will be the ones whose practitioners became builders first.
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
-30-
References
- Heena Purohit, Director of AI Startups, Microsoft, LinkedIn post on build versus buy and Boston Consulting Group’s report on AI alliances and joint ventures, November 2026. [Link]
- Yes, Virginia! There is more to e-procurement than software! (Part 1) — September 2007
- With IBX, purchasing isn’t just a business, it is a way of life — December 22, 2008
- Echoes of understanding: recent SAP post resonates with the readers — September 22, 2010
- What role have spreadsheets played in the “evolution of procurement technology?” — January 13, 2023
- What did the MAI Basic Four ISAs and these “Unicorns” have in common? Problem Solving! — November 5, 2023
- An Industry Veteran Poses A Tough Question About The Future Of AI — September 26, 2024
- The Five Most Important Questions To Understand The Future Of AI Procurement Platforms — September 27, 2024
- Duncan Jones Weighs In On Solution Provider Demo Reluctance — September 27, 2024
- Practitioner Heal Thy Own ProcureTech Initiative — November 8, 2024
- The Enterprise AI Divide: Personal AI Is Becoming the New Shadow Spreadsheet — July 16, 2026. https://procureinsights.com/2026/07/16/the-enterprise-ai-divide-personal-ai-is-becoming-the-new-shadow-spreadsheet/
Related
Build Versus Buy Is the Most Ridiculous Debate in the Industry Today. Here’s Why.
Posted on November 3, 2026
0
By Jon W. Hansen, FCIPS | Procurement Insights · November 2026
Practitioners, and end-user clients in general, must be builders before they become buyers!
Practitioners must have a builder’s mindset to start!
This week, Heena Purohit, Director of AI Startups at Microsoft, shared a Boston Consulting Group report with a provocative opening line: build versus buy is no longer the right question for enterprise AI. The better question, she wrote, is what you actually need to own.
The BCG report describes four strategies. Adopt, when a capability is widely available and offers little differentiation. Partner, when you need specialized capabilities but not ownership. Build, when your proprietary data, workflows or expertise create a competitive advantage. Buy, when a scarce capability is strategically critical and ownership creates a lasting advantage. Her takeaway: as AI capabilities become commodities, owning the technology matters less than owning what makes it valuable to your business, meaning your data, your workflows and your domain expertise.
I agree with her conclusion. But I would go further, because the debate itself is the problem.
Build versus buy is the most ridiculous debate in the industry today, because without Phase 0™, most organizations are not in a position to do either. It is like shopping for a car before you are old enough to drive.
You have to do both at the same time
Here is what the debate misses. Building and buying are not alternatives. A practitioner who cannot describe how their own operation actually works, including the workarounds, the informal handoffs, the conflicting incentives and the strands no system records, is not ready to build anything. And they are no more ready to buy, because they cannot tell whether what they are buying fits.
Two years ago, when Sievo hosted a panel on this exact question, I put it this way: with either option, practitioners must step up and take the lead in their own initiative’s success. If practitioners cannot do it for themselves, through the build option, they are not going to fare much better with the buy option.
That is what a builder’s mindset means. It does not mean writing your own software. It means understanding your operation the way a builder has to understand it, before anyone writes a line of code or signs a contract.
We have seen this before: the MAI Basic Four
Some of you will remember the MAI Basic Four. I do not just remember it: I have been in high tech since 1983, and I have direct, firsthand experience with industry-specific applications and the MAI Basic Four. In those early days, businesses from law offices and dental practices to restaurants and retailers built their own software to solve their own problems. The technology was an extension of a better process, built on their own experience and expertise. It was the adjunct to the process, not the definer of it.
Then someone in finance usually had a flash of insight. If the application worked this well for us, it would work for others in our sector, and licensing it would recover what we spent building it. Those businesses became the original solution-provider incubators.
Two things made that model work:
Practitioners were builders first, and buyers second, and the solutions were better for it.
Where it went wrong
Somewhere between the early mainframe era, when customers were expected to write their own software, and the all-encompassing turnkey enterprise suites that followed, the builder’s mindset was lost. The vendor’s optimism, the belief that technology can solve any problem, survived. The practitioner’s understanding of their own operation did not travel with it.
As I wrote in 2010, early failures were contained, usually limited to a desktop or a single application. Enterprise failures were not: Hershey’s and FoxMeyer Drug became the examples everyone cites. Two years earlier, I had pointed to Hewlett-Packard’s troubled supply chain implementation as proof that technical capability does not translate into process efficiency.
The shift to “create once, use many” made software scalable. It did not make human experience and expertise scalable. As I put it to Duncan Jones in 2024, you can give five people the same recipe, and one dish will turn out differently, even better, than the others. The more complex the recipe, the wider the gap. And as Tom Craig observed the same year, finance often turned enterprise ERP into an accounting tool, limiting how much of it was used, and paying for the rest.
Practitioners never stopped building
Here is the irony. Practitioners never stopped building. They just stopped getting credit for it.
I was introduced to VisiCalc, the first spreadsheet, in 1979. More than four decades later, the spreadsheet is still one of the tools supply chain managers rely on most, not because practitioners failed to adopt technology, but because the spreadsheet is where they build what their enterprise systems do not do. In July of this year, I described personal AI as the new shadow spreadsheet: adopted from the bottom up, outside what the enterprise can see.
The builder’s mindset is already there. Most organizations simply treat it as a compliance problem instead of the asset it is.
What the BCG report gets right, and what comes first
Heena’s question, what do you actually need to own, is the right one. Her answer is right too: your data, your workflows and your domain expertise. But notice what all three have in common. None of them can be bought, and none of them can be owned until they are understood.
That understanding is what Phase 0™ establishes. It starts from the outcome the operation is producing now and traces back, through the people, decisions, incentives, workarounds and dependencies that produce it. Only then can an organization decide what to adopt, what to partner for, what to build and what to buy, because only then does it know what problem it is actually trying to solve.
Virginia’s eVA program is the case I have returned to for nearly two decades. In 2007, I wrote that eVA’s leaders avoided the trap of the initiative becoming a software project. They shifted the emphasis from cost justification to process understanding and refinement. The software did the job it was required to do, but eVA’s effectiveness had little to do with the technology and much more to do with the methodology behind it.
Build to understand. Buy to scale.
The AI era is making the MAI Basic Four model possible again. Practitioners can build working tools themselves, quickly, from their own understanding of the work. That is not a threat to the buy decision. It is what makes a good buy decision possible.
Build to understand. Then buy, partner or adopt to scale what you have understood. Never buy what you do not understand, or what you believe you understand but have not investigated.
The winners will not be the organizations that own the most AI, or even the ones that know what not to own. They will be the ones whose practitioners became builders first.
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
-30-
References
Share this:
Like this:
Related