Build Is Back

For the last two decades, enterprise IT has been ruled by a simple principle: Do Not Build.

Buy, configure, integrate, customise lightly where you must, but do not build.

Why?

The principle emerged from the early days of SaaS and a reasonable observation: Enterprise software had become good enough that most organisations were better off standing on the shoulders of specialist vendors than building their own versions of mature categories. CRM, HR, finance, ITSM, collaboration, marketing automation, analytics. Why build it when it could be bought.

The principle hardened into orthodoxy. Buying became the default, while building retired as a distant exception. Whole generations of CIOs built careers on rationalising custom codebases, retiring bespoke systems, and consolidating around SaaS suites. The buy-not-build consensus became so entrenched that it stopped being debated - it was simply how things were done. That consensus is ending. The economics of build have changed enough that the buy-not-build equation now tilts, in a significant number of cases, the other way.

Before explaining why it is changing, it is worth being honest about why the original principle was correct.

Building in-house software was expensive. It required hiring and retaining engineers, who were scarce and expensive and prone to leaving. It required managing product, design, QA, and delivery functions that were not the enterprise’s core capability. It required long lead times, typically eighteen to thirty-six months from decision to production. It required ongoing maintenance, often at twenty to thirty per cent of the initial build cost annually, which compounded into a very large total cost of ownership over a decade.

Against this, buying was cheap and fast. A mature SaaS product could be procured in weeks, configured in months, and running in a year. The vendor took on the burden of development, maintenance, security, compliance, and continuous improvement. The enterprise paid an annual subscription and got access to a product that was, in most commodity categories, better than anything the enterprise could reasonably build for itself.

The maths worked for the vast majority of enterprise software categories, which is why the principle became the orthodoxy. The maths did not work for a small number of areas where the enterprise had genuinely differentiated needs, core trading systems at a bank, core logistics at a retailer, core safety systems at a miner. In these areas, building continued, because the “buy” option did not credibly exist. Everywhere else, buy won.

For twenty years, the defaults held.

Three things have changed, and they have not changed incrementally. They have changed by factors of three to ten.

The cost of writing software has collapsed. An engineer with modern AI tooling, operating at senior level, can produce in a week what a small team produced in a month three years ago. This is observable, measurable, and now uncontroversial in any engineering organisation that has actually measured it. The labour cost of producing working software has dropped by a factor of three to five for most workloads, and by a factor of ten for some. Not a marginal change!

The cost of maintaining software has dropped even more sharply. Maintenance, traditionally the largest fraction of total cost of ownership, is where the AI productivity gains are most pronounced. Debugging, refactoring, test generation, documentation, onboarding new engineers, keeping dependencies current, all of these are dramatically faster with proper tooling. A code base that used to require five engineers to maintain can now be maintained by one or two. The ten-year cost of owning software has fallen more steeply than the initial build cost.

The cost of customisation has dropped to near-zero. This is the most interesting of the three, and the least discussed. For twenty years, the hidden cost of buying SaaS was the cost of making the bought product fit the enterprise’s actual workflows. Enterprise SaaS is configurable, not flexible, and the gap between what the product does and what the enterprise needs is typically filled by a combination of expensive consulting, bolt-on tools, and operational workarounds. When build becomes cheap, the customisation premium of buying becomes a reason to build instead.

Put these three together and the build-versus-buy calculation changes across a wide range of categories. It does not flip in every category, but it flips in many. And the categories where it flips are precisely the ones where the enterprise has some degree of workflow distinctiveness, which is most of them.

The categories where the new build dividend is clearest share a few characteristics.

The enterprise’s workflow is genuinely different from the off-the-shelf product. If the SaaS product required heavy configuration or extensive bolt-on work to fit the enterprise, the calculus is now different. A focused build, tailored exactly to the workflow, often costs less to produce than the integration-heavy buy version and continues to cost less year on year. This is particularly true in operational domains, where workflows have accreted around the enterprise’s specific operating model and do not map cleanly to horizontal products.

The domain rewards depth that SaaS vendors have not captured. In some industries, horizontal SaaS has never done a good job of serving deep domain needs, and the enterprise has been paying for poor fit for years. In these areas, a focused build by an internal team that understands the domain can produce something that serves the actual need rather than a generalised approximation of it. Examples include risk modelling in reinsurance, clinical workflow in specialist healthcare, trading analytics in niche financial products, and operational monitoring in specific industrial contexts.

The enterprise’s data is central to the workflow and sensitive enough to resist externalisation. Many enterprise workflows involve data that is either strategically sensitive or regulated in ways that make externalisation risky. When the AI reasoning layer itself is the heart of the workflow, the question of where the data lives becomes more important than it used to be. For workflows where the data needs to stay inside the enterprise’s control, building becomes more attractive, because the alternative is either an expensive private deployment of a vendor product or an architecture that splits data and reasoning across organisational boundaries in uncomfortable ways.

The workflow is a real source of competitive advantage. Categories where the workflow itself is differentiating, how the enterprise decides on credit, how it prices insurance, how it manages logistics, how it triages customer issues, how it conducts trials, are categories where buying off the shelf gives the same capability to every competitor. Building produces a differentiated workflow that cannot be replicated by the next buyer of the same SaaS product. This was always true. It was previously too expensive to act on. It is no longer.

It is worth being clear that buy-not-build has not reversed universally. Buy still wins, and will continue to win, in several categories:

• Commodity functions where the workflow is genuinely the same across every enterprise. Basic finance, basic HR, basic collaboration, basic email, basic document storage. These are platforms, not workflows, and the scale economics of the SaaS vendor still beat anything an individual enterprise can build.

• Functions that require constant external integration with a sprawling ecosystem. CRM that needs to talk to dozens of marketing tools, or HR that needs to talk to dozens of payroll providers. The cost of maintaining an internal build that keeps up with a broad third-party ecosystem still favours buying from a vendor whose job it is to track that ecosystem.

• Functions where the vendor’s ongoing research investment is a material part of the value. Security tools, for example, where the vendor’s ongoing threat intelligence is integral to what is being purchased. No internal build can keep up with this.

• Functions where the regulatory burden is better carried by a vendor whose business is to carry it. Payments infrastructure, KYC/AML systems, certain compliance platforms etc. The vendor’s specialisation in the regulatory domain is the product, and replicating it internally is almost never worth it.

In all these cases, the build dividend does not flip the equation. It flips the equation in the middle ground, where the enterprise has been unhappy with its SaaS choices for years and has been quietly subsidising the vendor with customisation cost.

A common misconception is that “build is back” means returning to the pre-SaaS era of massive in-house IT departments and long development cycles. It does not.

The new build looks quite different from the old build. It is smaller. It is faster. It is built on top of mature platforms rather than from scratch. It leans heavily on AI-assisted and agentic development. It is often produced by small internal engineering teams, occasionally paired with specialist partners, rather than by large outsourced delivery organisations. It often takes the form of custom-built agents and workflows running on top of existing systems of record, rather than replacing the systems of record themselves.

Importantly, the new build is typically modular and composable. The enterprise is not rebuilding its ERP. It is building a specific workflow, or a specific agent, or a specific tool, that serves a specific differentiated need, while continuing to use off-the-shelf products for everything commodity. This is a very different posture from the pre-SaaS “build everything” model, and it reflects the fact that the economics now favour building specific, differentiated pieces on top of bought generalist infrastructure.

The teams doing the building are also different. They are smaller than enterprise engineering teams of the past, usually three to twenty people for a given workflow. They are staffed with AI-fluent engineers who get more leverage per head than was previously possible. They include embedded domain experts who would never have been on a traditional engineering team. They operate on weekly delivery cycles, not quarterly ones. They measure themselves by operational outcomes, not project milestones.

Enterprises that are figuring this out are building a new core capability that they did not have two years ago. Those that are not, and that are continuing to outsource or buy everything, are quietly falling behind.

For CIOs, the build dividend forces a change in how the portfolio is thought about.

The old portfolio classified everything as “buy, with some legacy build that is gradually being retired.” The new portfolio needs a “build again” category that is explicitly sized and funded. Not every workflow qualifies, but those that do need to be identified deliberately, and the enterprise needs to have the internal capability to execute against them. CIOs who do not build this capability in the next two to three years will watch their organisations lose workflow differentiation to competitors that did.

The portfolio discipline also needs to change. The old rule was that build projects were expensive, slow, and risky, and should be approved only reluctantly. The new rule is that build projects are in many categories cheaper, faster, and less risky than the high-customisation buy alternatives that looked like the safe choice. The CIO’s job is to evaluate this honestly for each category, not to apply the old default to the new economics.

The talent strategy needs to change. A CIO running a traditional buy-heavy organisation has mostly outsourced engineering capability and kept IT focused on vendor management, integration, and operations. Reintroducing meaningful internal build capability requires hiring differently, organising differently, and managing differently. This is a multi-year shift. Starting it late, after the advantage has settled, is more expensive than starting it early.

For SaaS vendors, the build dividend is a complication, but not a threat to the category as a whole.

Vendors in commodity categories should continue to thrive, because the build dividend does not flip the equation for them. Vendors in categories where buyers have been unhappy for years, and paying heavily for customisation, will see erosion. The enterprise that was going to grumble and keep paying will increasingly build instead. The vendor will see it in renewal churn first, and in new deal win rates second, and in net revenue retention third. The pattern will take three to five years to fully surface in the public metrics, but it has already started.

The strategic response for vendors in at-risk categories is not to resist the build dividend, which cannot be resisted, but to embrace it. Vendors who provide platform primitives that enterprises can build on top of, rather than finished applications the enterprise has to conform to, are in a much stronger position. This is why several of the most interesting enterprise software companies of the next decade will not look like traditional SaaS. They will look like platforms that make enterprise build cheaper, faster, and safer.

Build is making a come back because the arithmetic has changed, and the arithmetic is what determined the old orthodoxy in the first place. The enterprises that see this clearly will allocate capital differently over the next three to five years. They will increase internal engineering capability. They will reduce dependence on heavily customised SaaS. They will build differentiated workflows that their competitors cannot copy by buying the same tools. They will, quietly, develop an operational capability that in ten years looks like a meaningful competitive advantage.

In the next and final piece of this series, I want to synthesise the whole arc. After the unbundling, the rebundling, the margin reset, the workflow moats, the three systems, the identity crisis, the depth dividend, and the build dividend, what does the post-SaaS enterprise software stack actually look like. The shape of it is already visible, and it falls into four archetypes, each of which will produce its own set of category winners over the next decade.