Build, Buy or Compose?
Why Your Software Strategy Needs a Third Option
Build or buy. For decades, that question has been the starting point for almost every software decision. Open source and SaaS each reshaped the calculus in turn. Now AI is reshaping it again, and this time the change is more fundamental.
The question is no longer build versus buy. It is build, buy, or compose.
And the SaaS market is already feeling it.
Build, Buy, or Compose Framework
The Seat-Count Crisis
Something significant is happening in the SaaS market in 2026. The enterprise software sector has seen close to a trillion dollars wiped from its market value since the start of the year. The term is “SaaSpocalypse.” The underlying logic is straightforward.
Per-seat SaaS pricing assumes that software serves human users. You have 100 employees in your customer support team, you buy 100 licences. But what happens when AI agents can do the work of those 100 employees? You do not need 100 licences anymore. You might need 10. Or 5. Or none at all.
The Seat-Count Crisis
That changes everything.
This is the seat-count crisis. If your company once needed 500 licences for payroll or customer support, you might now achieve the same output with a fraction of that number by deploying autonomous AI agents. The budget is not disappearing; it is being redirected. AI budgets that barely existed three years ago now average 3–10% of total IT spend. The money is being reallocated directly from SaaS seat counts.
On the ASX, this is already playing out. Xero, WiseTech, and TechnologyOne have all traded well below recent peaks as investors reassess the durability of per-seat revenue models. Vertical SaaS is under the most pressure. These industry-specific tools covering legal, HR, payroll, logistics, and finance are precisely where AI agents are now performing entire workflows, not just assisting with tasks.
The SaaS vendors who see this coming are already pivoting their pricing models. Salesforce has launched what it calls an “Agentic Enterprise License Agreement”, a fixed-price, all-you-can-eat model that decouples revenue from seat count entirely. ServiceNow is moving to consumption-based pricing, where customers pay per automated incident resolution rather than per user. The vendors who survive this transition will be the ones who shift from selling seats to selling outcomes. The ones defending the legacy model will not.
I am not saying SaaS is dead.
There is a credible counterargument worth taking seriously: AI agents largely run on top of SaaS platforms, not instead of them. They call Salesforce APIs. They trigger ServiceNow workflows. They read from and write to the systems that already exist. The best SaaS products have deep workflow integration, strong network effects, and data moats that are genuinely hard to replicate.
But an AI agent making API calls does not need a UI. It does not need onboarding. It does not justify a per-seat fee. SaaS vendors who adapt to this reality by pricing on API consumption, outcomes delivered, or data processed will survive. The ones who insist an API call equals a seat will not.
The automatic default of “just buy a SaaS tool” deserves more scrutiny than it used to. The question is no longer whether the product is good. It is whether the pricing model survives contact with agents.
The Problem With Build Right Now
Building bespoke software has its own set of challenges, and AI has not made all of them disappear.
The first problem is that bespoke software requires training. If you build a custom solution to solve a business problem, everyone who uses it has to learn your way of doing things. That works fine for technical staff, but think about the front counter of a retailer, or a sales team, or a warehouse operation. There is real value in buying software that your new hires already know how to use. We chose Salesforce for a sales organisation I worked with not because it was the best CRM available, but because every salesperson we hired was already trained in it. That is a legitimate business advantage.
The second problem is maintenance. Every piece of bespoke software you build becomes something you have to maintain, support, update, and improve over time. You need to collect feedback from users, fix bugs, manage releases, and keep the system current. This is product management, and it does not go away just because AI made the initial build faster.
The third problem is proliferation, and it is getting worse. If AI makes it easy to build a small custom tool for every business problem, you can quickly end up with dozens of disconnected applications. Each solves a specific problem. Collectively, they create a new integration and governance burden. Retool’s 2026 Build vs. Buy report tells the story. 35% of enterprises have already replaced at least one SaaS tool with a custom build. 78% plan to build more this year. Much of this is happening outside traditional IT guardrails. Shadow IT is back, not in the old form of unsanctioned SaaS subscriptions, but as unsanctioned custom-built tools created by teams who can now actually ship software. The governance problem used to be people signing up to Dropbox without telling IT. Now it is people building applications without telling IT.
These problems are real, but here is the thing: AI has changed the severity of all of them. The key-person dependency problem has largely been solved. If your smart developer builds a custom system and then leaves, an AI can now read that code, understand it, and support it. Maintenance costs have dropped because AI accelerates every part of the development cycle. And integrations that used to take a developer several days to build and test can now be written in an hour.
So build is better than it was. Significantly better.
But it is still not always the right answer.
The Third Option: Compose
Here is what I think is actually happening. AI has not just changed the cost of building software. It has created an entirely new approach that sits between build and buy.
Composing means assembling a solution from AI agents, open source tools, and lightweight integrations, rather than building it from scratch or buying a monolithic SaaS product. You are not writing a full application. You are not buying a full suite. You are orchestrating a set of components that together solve your specific problem.
I have been doing this without explicitly naming it. The triage system I described in recent articles was composed from NMIS, n8n, Claude Code, and Slack. All open source or self-hosted. No per-seat SaaS licence for the core function. Two years ago, that would have required a dedicated developer for months. With AI assisting the build, it took days. It came with documentation, test coverage, and the ability for any subsequent developer or AI to pick it up and extend it. The integration work that used to be the hardest part is now straightforward.
A Composed Solution
The conversation has moved beyond technology circles. Logistics and supply chain teams are now asking whether they should compose their own transport management systems rather than buy one. When operational teams start asking software architecture questions, the shift is real.
The New Questions to Ask
The build versus buy framework gave you a useful set of questions. The compose option adds new ones.
Ask This Before You Decide
On the buy side, ask: - Is this product’s value in its data network, its integrations, or its shared standards? If so, buy, those things are hard to replicate. - Does my team already know this tool? Retraining costs are real. - Is the vendor embedding AI to stay competitive, or defending a legacy model? (This is the question that will separate the survivors from the casualties over the next 24 months.)
On the build side, ask: - Is this a core differentiator for my business, or a commodity function? Build for differentiation; buy or compose for commodity. - Can I accept the ongoing product management burden? - Will AI-assisted maintenance keep the total cost of ownership acceptable over time? (If you cannot answer this confidently, you are not ready to build.)
On the compose side, ask: - Can I solve this problem by orchestrating existing open source tools and AI agents? (Start here. You will be surprised how often the answer is yes.) - What is the integration surface – how many systems need to talk to each other? - Am I building something that needs to scale to thousands of users, or something that serves my internal operations?
The honest answer is that you will probably end up doing all three, often for different problems within the same business. The mistake is defaulting to buy for everything because it was the safe choice for the last decade, without re-examining whether that assumption still holds.
Two Things Compose Does Not Fix
The quality gap is real. A CodeRabbit analysis of pull requests from late 2025 found that code co-authored by AI contains approximately 1.7 times more major issues than human-written code. The barrier to assembling a working system has dropped dramatically. But working is not the same as secure, and fast is not the same as correct. If you are composing solutions, you need a review step that did not exist when a senior developer wrote every line. The compose approach does not remove the need for quality judgement. It makes it more important, because the volume of code you can generate now far exceeds what any team could previously produce or review.
Product management is still required. Whichever path you choose, someone needs to own the outcome. Gathering feedback, prioritising improvements, managing the user relationship. AI accelerates execution. It does not replace the discipline of treating your internal tools as products.
The Bottom Line
The build versus buy question served us well for decades. It needs to be updated.
The new question is: build, buy, or compose? And for a growing category of business problems, compose is the most pragmatic, cost-effective, and flexible answer available. But compose done badly is just shadow IT with better tooling. The organisations that get this right will combine AI speed with real governance. The old SaaS default provided that discipline almost by accident. Compose requires you to provide it on purpose.
Better information means better decisions. If you reassess your software strategy in light of what AI has actually made possible, not as a feature bolt-on to existing SaaS, but as a fundamental shift in what you can build and compose, you will have a genuine competitive advantage. Starting now.
The rest will be paying for seat licences they do not need.