Here's the short answer: in 2026, the default for most product capabilities is neither build nor buy. It's wire together, meaning you buy API-first services and compose them into something that behaves like custom software. Reserve genuine building for the one or two capabilities where your product actually differentiates, and reserve pure buying for commodity functions you'll never touch again. Everything else lives in the middle.
The old framing treated this as a binary. You either wrote the code yourself or you signed a SaaS contract and accepted whatever the vendor shipped. That framing died quietly over the last few years as platforms like Stripe and Twilio proved that a purchased service with a well-designed API can be extended until it fits your workflow almost exactly.
The default answer changed, and the data shows it
Two shifts drove this. First, API-first became the norm rather than the exception. Postman's 2024 State of the API report, drawn from over 5,600 respondents, found 74% of organisations now describe themselves as API-first, up from 66% the year before. When most of the software you might buy is designed to be composed, wiring together stops being a compromise and becomes the intended usage pattern.
Second, building got dramatically cheaper, which paradoxically made teams more willing to do it. Retool's 2026 Build vs Buy report, surveying 817 builders in late 2025, found 35% had already replaced at least one SaaS tool with a custom build, and 78% expected to build more of their own tools in 2026. The same survey found 60% had built something outside IT oversight in the past year, which tells you the demand for tailored software now outruns most companies' governance.
Cheap building is a trap if you read it naively. The cost that dropped was writing the first version. The costs that didn't drop are maintenance, security patching, compliance and the salary of whoever owns it in year three. That's why the wire-together middle path keeps winning: someone else carries the operational burden while you keep control of the workflow.
When building genuinely wins
Build when the capability is your moat. If your pricing engine, matching algorithm or data model is the reason customers choose you, owning that code is not optional. Build also when no vendor's abstraction fits, because forcing a core workflow into someone else's schema costs more in workarounds than the subscription saves.
Everything else deserves scepticism. A custom authentication system, a hand-rolled analytics pipeline or a bespoke CMS rarely survives contact with the third engineer who inherits it. Gartner's survey of more than 2,000 CIOs found that 63% of leaders at highly composable organisations reported superior business performance against peers. Composability, not code ownership, correlated with results.
This is exactly the sorting exercise we run during technical architecture and planning engagements: map every capability, tag it as differentiating or commodity, then assign build, buy or compose before a line of code exists.
A decision test you can run in an afternoon
For each capability, ask three questions. Does it differentiate us with customers? Will requirements change faster than a vendor roadmap? Can we staff its maintenance for three years? Three yeses point to build. Three noes point to buy. Anything mixed points to wiring together an API-first service, which is where most answers land.
The illustrative split above reflects the pattern the MACH Alliance has been describing for years: composable pieces dominate, genuine custom code is the thin differentiating layer, and pure off-the-shelf purchases handle the commodity edges.
One warning from experience: wire-together is not free. Every integration is a contract with a vendor's uptime, rate limits and deprecation schedule. Budget for an abstraction layer around any API you'd struggle to replace within a quarter.
FAQ
Is building cheaper now that AI writes most of the code?
The first version is cheaper, often dramatically so. Total cost of ownership is not, because maintenance, security and compliance costs are unchanged. Price the three-year cost, not the demo.
What should a startup never build?
Authentication, payments, email delivery and basic analytics. These are solved, regulated, API-first categories where custom code adds risk without adding differentiation.
How many vendors is too many?
When no single engineer can sketch the data flow across your stack from memory, you've crossed the line. Consolidate before adding the next service.
Your five-step decision checklist
1. List every capability your product needs over the next 18 months.
2. Tag each one as differentiating or commodity, and be ruthless about it.
3. Run the three-question test: differentiation, pace of change, maintenance capacity.
4. For every compose decision, note the switching cost and wrap fragile APIs.
5. Revisit the map every six months, because vendor capabilities move quickly.
If you'd like a second pair of eyes on that map, BeyondPixl Studio runs architecture planning sprints that turn a capability list into a costed build, buy or compose blueprint in under two weeks. Book an architecture review and bring your messiest integration diagram.