Every company that uses software eventually faces a version of the same question: should we pay a vendor for this, or build it ourselves? For most of commercial software history, the answer leaned heavily toward buying. That answer is shifting, and the implications are uncomfortable for vendors and buyers alike.

Where the question came from

Before packaged software existed, every company that needed software built it. Payroll systems, inventory tracking, order management: all custom, all internal. Then, in the 1970s and 80s, the commercial software industry emerged. Companies like SAP and Oracle began selling enterprise software that handled entire business functions in one system.

SAP's ERP is the canonical example of why buying made sense. ERP, or Enterprise Resource Planning, is software that unifies a company's core operations: accounting, HR, procurement, inventory, manufacturing, supply chain. It is enormously complex. SAP spent years building their system, handling edge cases across dozens of industries and thousands of business scenarios. No individual company could justify that investment. But SAP could, because the cost spread across every customer they sold to.

The economics were clear: a vendor could invest far more in a specialized product than any single buyer could, and every buyer got access to the depth of that investment for a fraction of the cost. The conventional wisdom that emerged from this era was intuitive: buy for commodity functions, build only for competitive advantage. Don't build your own payroll system. Do build your recommendation engine if recommendations are your product.

The case for buy vs. build

The arguments for buying were strong. Vendors specialized deeply. They had teams dedicated to a single product, absorbing requirements and edge cases that no individual company would think to handle. Buying meant faster time to value, a predictable cost structure, and someone else responsible for maintenance. It also usually meant a breadth of features that internal teams could rarely match.

Building had real advantages too. Full control over the product, no vendor lock-in, the ability to customize to exact requirements, and ownership of the underlying logic and data. But those advantages came at a cost that was easy to underestimate: not just the initial build, but ongoing maintenance. Software doesn't sit still. Requirements change, infrastructure evolves, and bugs surface in production. The team that built the thing becomes responsible for it indefinitely. For anything that wasn't central to the business, that tradeoff rarely made sense.

What changed in the following decades

The 2000s introduced SaaS and made buying even easier. No installation, no on-premise infrastructure, subscription pricing, and tools that teams could adopt in days rather than months. The barrier to buying dropped further. Open source offered a middle path: free to use, but still requiring someone to run it, upgrade it, and handle whatever it didn't do out of the box. For most companies, the commercial option remained the practical choice.

Throughout this period, the underlying calculus stayed roughly constant. The expertise gap between a vendor and an internal team was wide. Vendors had specialists. Internal teams had generalists stretched across many priorities. Building anything serious required experienced developers, long timelines, and a maintenance commitment that compounded over time. The wisdom held: buy the commodity, build the moat.

AI changes everything

The cost of building has dropped substantially over the last few years, and it continues to drop. AI helps with scaffolding, boilerplate, integrations, debugging, and iteration. A developer who isn't a specialist in a domain can now produce credible software in that domain, because AI fills the knowledge gaps that used to require years of experience. Tasks that once took a team months can take a single developer weeks.

Things that once lived firmly in the "buy" column have crossed into "build." The long tail of software that companies bought because building was too expensive is now buildable, by smaller teams, faster, with less expertise required. Internal tools, custom integrations, specialized data pipelines: these were always better built than bought in principle, but the cost made buying the only practical option. That's no longer the case. The gap has closed, and it will keep closing. This doesn't mean building is free or easy. The threshold has moved, not disappeared.

The principle hasn't changed. Buy for commodity, build for advantage still holds. What AI has changed is where that line falls. More things that used to be "buy because you can't afford to build it" are becoming "build because you can now afford to." And the pace of that shift is accelerating.

What this means in practice

This is where the implications get uncomfortable.

If building is getting easier every year, the natural question for any buyer is: why pay for something I could build myself? A SaaS product that solves a narrow, well-defined problem is increasingly at risk of being replaced by something a team assembled in a few days with AI assistance. The economics that once made buying obvious are changing.

But there is a cost that the initial build effort consistently hides: ownership. Software isn't done when it ships. It needs to be updated when dependencies change, extended when requirements grow, debugged when production breaks, and understood by whoever inherits it. That burden accumulates. A tool built in a weekend can quietly become a recurring weekend every month. The question isn't how much effort it takes to build something. It's how much effort it takes to own it over time.

This is the real tension in the buy vs. build decision today. For a buyer: how much can we build for ourselves before the management and maintenance burden exceeds what a vendor would charge? The answer isn't the same for every team. A small team with limited engineering capacity has a lower threshold than a platform team with dedicated infrastructure engineers. A tool that rarely changes is cheaper to maintain than one that needs constant updates to stay current.

For a vendor, the question is harder. How do you build a product that a customer will value more than something they could build themselves? Price used to answer that question. If building cost ten times as much as buying, the math was simple. Now, for narrower tools, the gap has closed. A team can often replicate basic functionality faster than a sales cycle closes.

What remains is depth. A mature product has years of production exposure. It has encountered the edge cases, handled the bad inputs, survived the scale spikes, and integrated with everything the customer was already running. That's real value, and it's hard to reproduce quickly. But it's also invisible in a demo. Vendors who have been selling on surface-level features are the most exposed. Vendors who have been solving the hard problems, the ones that only surface after months of real-world use, are the ones whose products remain difficult to replicate.

The line between buy and build is not fixed. It is moving, and it is moving toward build. The question both sides are now trying to answer is the same one it has always been: is this worth doing yourself, or is someone else already doing it better? The difference is that "better" is a higher bar than it used to be.

Nobody is going to pay for software they can build with minimal effort. The products worth paying for are the ones where the effort isn't minimal, even with AI. Finding and communicating that clearly is, increasingly, what the buy vs. build question is really about.