At TRW — a Fortune 122 diversified technology company — one of the questions I was brought in to help answer was whether to build a custom enterprise database-replication mechanism for inventory control or adopt existing commercial software. The comparative cost, the integration constraints, the maintenance burden on each path, the organizational capability to support each option — working through those specifics took months.
In the AI era, the same question has a third option that complicates the analysis in useful ways. But the fundamental strategic logic has not changed.
quadrantChart title Enterprise Software Investment in the AI Era x-axis Low Strategic Differentiation --> High Strategic Differentiation y-axis Low AI Acceleration Potential --> High AI Acceleration Potential quadrant-1 Build custom with AI assist quadrant-2 Automate existing workflows quadrant-3 Buy off the shelf quadrant-4 Extend with AI augmentation Customer-facing platform: [0.82, 0.75] Reporting and analytics: [0.28, 0.85] CRM and sales workflow: [0.18, 0.60] Core data infrastructure: [0.75, 0.48] Internal tooling: [0.35, 0.70]
What the Build / Buy Framework Actually Is
Every enterprise software decision sits somewhere on two axes.
The first is strategic differentiation: does this software encode something about how your business operates that competitors cannot easily replicate? A proprietary pricing model, a workflow that reflects 20 years of domain knowledge, a data processing capability specific to your customer base — these are differentiated. Authentication, expense reporting, scheduling, customer service routing — these are not.
The second is integration dependency: how tightly does this software need to connect to the rest of your technical estate? High integration dependency raises the cost of buying a solution not designed for your environment, because every integration point becomes a customization. It raises the cost of building, too, but the cost is known rather than discovered post-deployment.
The right call on any specific decision depends on where it falls on those two axes. The AI era has not changed the framework. It has changed several of the inputs.
What AI Changes in the Analysis
The cost of certain kinds of custom development has dropped. AI coding assistance reduces the time and labor required to build systems that follow well-understood patterns — CRUD applications, integration adapters, reporting layers, workflow automation, internal tooling. What would have required a team of three engineers and six months might now require one engineer and two months with AI assistance. That changes the build-versus-buy math on a specific class of problems.
It does not change the math on everything. Building software still requires architectural judgment, security review, testing, documentation, and a maintenance plan. AI accelerates the generation phase; it doesn’t eliminate the governance work that makes a codebase maintainable five years later.
The practical implication: AI lowers the cost threshold for building differentiated software. Problems that were previously not worth building because the ROI didn’t justify the development cost may now be worth building. That is a genuine shift. The mistake is reading it as a reason to build everything. The more useful question is still: does this encode something specific to how we operate, or is it commodity infrastructure that someone else has already solved?
At TRW, the eventual recommendation on the database-replication question was to weigh the long-term operational cost of custom maintenance against the integration flexibility it provided. AI doesn’t eliminate that analysis. It changes the input values.
The Enterprise Software Debt Problem in the AI Era
First American Financial spent a decade acquiring more than 80 companies. By the time I was working there as enterprise architect, the organization had accumulated over 700 software applications — dozens of overlapping CRM systems, redundant policy management tools, half-integrated data pipelines that had been promised post-close and never finished. The consolidation and remediation work was one of the most expensive consequences of the acquisition strategy, and it was rarely counted in the deal economics.
AI-era enterprises are creating a version of the same problem without acquisitions.
When AI coding assistance is adopted without portfolio governance — when teams across the organization each use AI to build systems, internal tools, automation workflows, and data pipelines — the catalog grows faster than governance can keep up. Six months later, there are four different AI-generated versions of the same workflow, built by different teams, integrated differently, documented inconsistently, and owned by nobody.
The solution is not to restrict AI adoption. It is to apply the same portfolio logic to AI-generated software that mature companies apply to acquired software: catalog it, look for overlap, make deliberate decisions about what to consolidate, and establish an architectural standard that new AI-generated work has to meet before it gets added to the estate.
The Decisions That Matter Most Now
The most consequential enterprise software strategy decisions in the AI era are not about which AI tools to buy. They are about portfolio governance.
What is the threshold for building something new versus buying or extending something existing, and has that threshold been adjusted to account for the new AI-assisted cost of custom development?
What is the architectural standard that AI-generated code has to meet before it enters the production estate?
Who owns the catalog? Not the backlog, not the sprint plan — the full picture of what software the organization operates and who is accountable for each piece.
These decisions determine whether AI acceleration compounds or degrades over time. The companies that get this right will have a leaner, more coherent software estate at the end of the decade than they started with. The ones that don’t will spend the early 2030s doing what large enterprises spent the 2000s doing: consolidating an estate that grew faster than anyone tracked it.