Two trends dominated enterprise software commentary in early 2026, and they were almost always discussed in separate rooms. Put them in the same room and the conversation changes.
The first trend has a name procurement teams have started using through gritted teeth: the AI Tax. As vendors bundle AI features into existing products and migrate customers onto pricier AI-inclusive editions, renewal quotes have been climbing with one analysis, in the range of 20% to 37% for software that does roughly what it did last year, now with an agent stapled to it. The broader repricing has been violent enough that the sector earned the nickname “SaaSpocalypse,” with the software ETF down more than 20% year-to-date at one point and an enormous amount of market capitalization erased as investors repriced the per-seat model itself. The seat, as the obituaries put it, is dying and revenue is being unhitched from headcount and re-hitched to outcomes and consumption.
The second trend got covered as a developer-productivity story and filed under “neat”: AI has collapsed the cost of building software. Tasks that required a team now require a person and a set of tools. The cost, the calendar, and the headcount of building custom software have all fallen at the same time.
Held apart, these are two interesting observations. Held together, they describe an inversion in one of the oldest decisions in enterprise technology.
The math that used to settle the argument
Build-versus-buy was, for two decades, a fairly settled calculation. Building was expensive, slow, and risky. It required a team you had to hire, manage, and retain. Buying was the responsible default: faster, cheaper, supported, and someone else’s maintenance problem. “Don’t build what you can buy” was not a slogan, it was sound arithmetic. The premium you paid a vendor was almost always less than the fully loaded cost of building and owning the equivalent yourself.
That arithmetic had two inputs: the cost of buying and the cost of building. In 2026, both moved. And they both moved in opposite directions.
The cost of buying went up, via the AI Tax and the migration to consumption and outcome-based models that make the annual spend less predictable and frequently larger. The cost of building went down, via AI-assisted development that lets a very small team, or a genuinely well-equipped individual, to produce what used to demand a department.
When one side of a comparison rises and the other falls, the comparison can flip. For a meaningful and growing set of cases, it has.
What “buildable” now includes
The reflexive objection is that this only applies to trivial software and that real, production-grade, platform-native applications are still firmly in buy territory. That objection is aging quickly.
Consider the existence proof. On the Salesforce platform, building a properly packaged second-generation managed application, the kind of artifact that historically implied a funded product team, is now within reach of an operation running lean on AI-assisted development. Resource Interactive runs as a product team of one plus AI and ships a portfolio of Salesforce-native managed packages to the AppExchange on exactly that model. The relevant point is not the company. It is the proof: if a single operator can produce platform-native, security-reviewed, packaged applications, then the floor for what counts as “buildable rather than buy-only” has dropped through the basement, and the build-vs-buy line has to be redrawn.
This does not mean build everything. Buying still wins decisively where the problem is genuinely commodity, where the vendor has deep domain investment you cannot replicate, or where the maintenance burden of ownership outweighs the licensing premium. The point is narrower and more useful: the default has changed. “Buy unless you have a strong reason to build” is no longer automatically the conservative answer. In a world of rising AI Tax and collapsing build cost, “buy” can be the expensive, lock-in-heavy choice, and “build” can be the prudent one. The burden of proof has shifted sides.
The decision worth re-running
The trap is treating build-vs-buy as a decision you made once. Most organizations settled it years ago, under the old arithmetic, and have been re-applying the conclusion ever since without re-checking the inputs. The inputs changed. The renewal quote climbing 30% and the build cost falling by more than that are not two separate news items, they are the two terms of the same equation, and the equation now produces a different answer than it did eighteen months ago.
The organizations that notice will re-run the calculation on their next few renewals and find that some of what they reflexively buy, they could now build that is better-fitted, free of the AI Tax, and free of the lock-in that made the renewal quote a take-it-or-leave-it proposition in the first place. The ones that don’t notice will keep paying the rising tax on the assumption that building is still the expensive option.