For most of the past 30 years, “build vs. buy” was primarily a cost conversation. Custom software was expensive — senior engineers, long timelines, integration risk, ongoing maintenance. So you bought when the use case was standard and built only when competitive differentiation required it and the budget supported it. The math on that trade-off has shifted. AI-assisted development has moved the build cost curve down materially, and that change makes the build vs. buy decision worth re-evaluating across your entire software portfolio.
This is not an argument for building everything. The buy case remains strong in specific scenarios. But the scenarios where building is the better economic decision have expanded, and most enterprise software portfolios were last evaluated against a cost structure that no longer applies.
quadrantChart title Build vs. Buy in the AI Era x-axis Low Competitive Differentiation --> High Competitive Differentiation y-axis Low Build Complexity --> High Build Complexity quadrant-1 Evaluate carefully — build if differentiation justifies it quadrant-2 Build with AI assistance — speed and control quadrant-3 Buy — commodity functionality quadrant-4 Buy or build quickly — fast wins Internal reporting layer: [0.68, 0.22] Core workflow engine: [0.80, 0.72] Authentication system: [0.18, 0.38] AI feature with proprietary data: [0.82, 0.58] Standard CRM: [0.15, 0.45]
What AI Has Actually Changed
The primary change is development speed for well-scoped work. Software that required two senior engineers and six months to build with high quality can now be built by one engineer working with AI coding assistance in a fraction of that time — if the scope is well-defined, the architecture decisions are made deliberately, and the output is reviewed carefully.
The secondary change is the cost structure of exploration. Building a proof-of-concept to validate integration assumptions before committing to a full build is now fast enough that it is a reasonable pre-purchase step rather than a significant investment. You can now test whether the custom build hypothesis actually holds before signing the contract.
What AI has not changed: integration complexity, data model quality, ongoing maintenance ownership, and the organizational discipline required to build software that lasts more than 18 months. The temptation to assume that fast build equals low total cost of ownership is a significant current risk. Build velocity is not the same as build quality, and a codebase that was generated quickly without deliberate architectural oversight compounds that debt as it grows.
The Cases Where Buying Still Wins
Commodity functionality. Authentication, billing, payments, CRM for standard sales motions, communication infrastructure — these are areas where the use case is standard across thousands of companies and the vendors have absorbed years of edge case handling, security hardening, and regulatory compliance work. The build cost may have come down, but the total cost of ownership for a custom authentication system — including the security maintenance, the edge case handling, and the ongoing compliance work — still exceeds what a well-chosen vendor solution costs.
Regulated functionality. Any software capability where the compliance surface is complex and well-served by existing vendors. HIPAA-compliant health data handling, SOX-compliant financial controls, PCI-compliant payment processing. The vendors in these spaces have absorbed the regulatory expertise into the product. Building a custom version means absorbing that expertise yourself.
Speed-to-market where differentiation is elsewhere. If a capability needs to be in production in 30 days and the build approach requires 90 days even with AI assistance, buy. The competitive advantage is not in the tool; it is in how fast you execute on what the tool enables.
The Cases Where Building Now Makes More Sense
Core workflow engines that are genuinely specific to the business. If the workflow that drives your revenue model has enough domain-specific logic that COTS solutions require significant customization to fit it, the customization cost often exceeds what a clean custom build would cost. And after customization, you own a modified version of a vendor product that is harder to maintain than either a clean build or a clean vendor instance.
AI features that depend on proprietary data. If the AI capability you are building depends on data that is unique to your business — proprietary transaction records, specialized domain knowledge, unique customer behavior patterns — a custom build with AI assistance is now financially feasible in a way it was not three years ago. The question is whether the competitive advantage from that proprietary data justifies the build investment.
Internal tooling where the integration depth requirement is high. Internal tools that need to integrate deeply with multiple internal systems are notoriously poor fits for general-purpose COTS solutions. The integration cost of buying and customizing frequently exceeds the cost of building with AI assistance — and the custom build typically integrates more cleanly.
What Happens When You Buy Without the Integration Evaluation
First American Financial had acquired more than 80 companies in the prior decade and was carrying roughly 700 software applications across 15+ subsidiaries. I was part of the architecture team that spent months auditing that estate — overlapping CRMs, redundant policy management systems, half-integrated data pipelines that had been promised post-close and never finished.
The pattern was consistent: each acquisition came with a buy decision that looked sound at the time. The integration cost that emerged post-purchase accumulated into a technology estate that cost more to operate than any individual acquisition had been expected to cost. When the full picture was visible — 700 applications, 15+ subsidiaries, an integration landscape that was growing more complex with every new acquisition — the cost of getting the build vs. buy decision wrong repeatedly was quantifiable in the nine figures.
The lesson is not that you should always build. It is that software designed and built with executive oversight — with deliberate architectural decisions and a clear integration plan evaluated against your actual data model — becomes a measurable driver of impact and company valuation rather than a cost center. The AI era makes building more economically feasible for a wider set of use cases, but it does not remove the requirement for that deliberate evaluation before the decision is made.
How to Run the Decision
For any significant software investment, the evaluation should now include three steps that were cost-prohibitive before AI-assisted development:
Scope test. Build a proof-of-concept of the core integration before making the build vs. buy decision. If the build path hits unexpected complexity in the first integration attempt, that complexity is in your actual environment — not in a demo. The buy path may have looked better than it appeared.
Customization audit. Before selecting a COTS solution, model what the integration and customization cost will actually be in your environment. Not the vendor’s estimate — your own evaluation of how their data model maps to yours and what the gap requires.
Total cost of ownership over three years. The year-one cost comparison between build and buy almost always favors buy. The three-year comparison frequently does not, once integration maintenance, customization maintenance, and vendor pricing changes are included.
The build vs. buy decision made well produces technology that is fit for its purpose and economically rational over its lifetime. Made poorly — or not made deliberately at all — it produces the integration estate problem that First American illustrated at scale.
