For more than two decades, enterprise technology sourcing has followed a familiar principle:

Buy before build.

The logic was sound. Commercial software could spread development costs across many customers, accelerate implementation and transfer parts of maintenance, security and updating to specialised vendors. Custom development was considered slower, riskier and more likely to create technical debt.

The logic has not become wrong. But a sensible preference has often hardened into an automatic rule.

Software is no longer a peripheral IT expense. U.S. private non-residential investment in software increased from an annualised $336 billion in the first quarter of 2016 to $798 billion in the first quarter of 2026. The measure covers software as an investment asset rather than purchased enterprise applications alone, but the ten-year development shows how deeply software has become embedded in corporate capital formation.

The sourcing decision therefore deserves more than an inherited management rule.

Signal 1: The Economics of Building Are Changing

Cloud platforms, open-source components, APIs and reusable services had already reduced the need to build every layer internally. AI-assisted development may now lower the effort required for prototyping, coding, testing, documentation and maintenance further.

The evidence is still emerging and does not yet cover a full technology cycle. A field study involving 4,867 developers at Microsoft, Accenture and another Fortune 100 company found a 26.08% increase in completed tasks among developers using an AI coding assistant. By contrast, a METR study found that experienced open-source developers working on familiar repositories took 19% longer with early-2025 AI tools. METR later reported indications of improvement, but said selection effects prevented a reliable estimate.

The executive conclusion is not that AI has made custom development universally cheaper.

It is that previous assumptions about the cost and speed of building have become less reliable—and should now be measured rather than presumed.

Signal 2: Buying Does Not Remove Complexity

Buying software can reduce initial delivery risk, particularly for standardised capabilities such as accounting, payroll or infrastructure management.

But it does not eliminate implementation, configuration, integration, data migration, operational dependence or eventual exit costs. It can also create lock-in and substantial opportunity costs.

The relevant comparison is therefore not:

Licence price versus development cost.

It is:

The full lifecycle economics of buying, adapting, operating, changing and eventually replacing the capability.

Buying may still be the better answer. It is not automatically the more flexible one.

Signal 3: The Boundary Is Becoming Dynamic

The practical choice is increasingly not binary. An organisation can buy a standard platform, use external models and open-source components, and build proprietary workflows, controls, data layers and customer experiences around them.

The emerging principle is to buy standardised capabilities while reserving custom development for areas where proprietary data, domain logic or workflows create defensible advantage.

Building capacity will nevertheless remain a serious institutional commitment. The U.S. Bureau of Labor Statistics projects software-developer employment to increase by 15.8% between 2024 and 2034, adding approximately 267,700 positions over the decade. The forecast does not prove that organisations should build more internally, but it indicates that software-engineering capability will remain strategically relevant—and unlikely to become effortless or abundant.

What Has Not Changed

Building still requires product ownership, secure development, architecture, testing, documentation, operational support and long-term maintenance.

AI-generated code does not remove these responsibilities. NIST continues to emphasise secure development, code review, verification, testing and human validation of AI-generated content.

Building can also replace vendor dependency with dependence on internal architecture, scarce expertise and accumulated technical debt.

The objective is not to maximise the amount of internally produced software.

It is to control the capabilities that matter.

The Better Decision

Buy-before-build should be replaced by neither build-first nor build-everything.

Buy what is standard. Build what differentiates. Continuously reassess the boundary.

This turns software sourcing from a procurement preference into a capital-allocation decision based on strategic value, lifecycle economics, control and reversibility.

Three Executive Questions

  1. Which capabilities encode proprietary workflows, data or customer experiences that competitors should not be able to purchase in the same form?
  2. What is the full lifecycle cost of buying, building, changing and eventually exiting each option?
  3. Do we possess the product ownership, engineering, security and operational capacity to operate what we build after the initial launch?

Bottom Line

The end of buy-before-build is not the beginning of build-everything.

It is the end of sourcing by default.

References

  1. AWS, Revisiting Buy vs. Build: 3 Traps to Avoid. View source
  2. Federal Reserve Bank of St. Louis, Private Fixed Investment in Intellectual Property Products: Software. View source
  3. Microsoft Research, The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. View source
  4. McKinsey & Company, Bridging the great AI agent and ERP divide to unlock value at scale. View source
  5. U.S. Bureau of Labor Statistics, Artificial intelligence, information technology, and employment projections, 2024–34. View source
  6. NIST, Software Supply Chain Security Guidance. View source