Vibe-coding has changed the build-versus-buy equation, but not in the way many people assume.

The old decision used to revolve around cost, control and customisation. AI has clearly shifted that balance by making software much easier to start. Teams can move from idea to prototype in hours. Internal tools that once needed a roadmap, budget and delivery team can now be assembled quickly, sometimes faster than procurement can even define a vendor shortlist.

That is real progress.

But vibe-coding changes the cost of starting, not the cost of owning.

Starting Is Easier Than Owning

That distinction matters. Generating a Python API endpoint is easy. Productionising an API that multiple teams rely on, with versioning, authentication, observability, retry behaviour, failure handling and multiple consumers, is not. The same applies to underwriting workbenches: what starts as a form connected to an endpoint becomes far more complex once manual overrides, referral logic, auditability, role-based permissions and deep interaction with a rating engine are required.

The outer layer is easier to build. The operational core is not.

Where Complexity Really Lives

The hardest parts of these systems are rarely the first visualisations or API calls. They sit in the shared foundations underneath them: identity and permissions, model development and simulation, scenario and version management, auditability and approvals, and the controlled deployment, monitoring and rollback of rates or models. These are not peripheral features. They are the operating foundation.

In many systems, the real value sits in the artefacts, not just the environment in which they are built. The model, the scenario, the simulation, the rate table, the approval trail and the deployed outcome often matter more than the interface alone. The interface still matters, and a workflow that creates real lift can justify serious investment. But in many cases it is not the main source of durable advantage by itself.

How AI Changes Buying

This will change how future software is built. The winners will not be rigid applications, but adaptable systems with robust shared primitives and enough flexibility for customers to shape the final workflow and interface themselves, increasingly with the help of large language models.

That strengthens, rather than weakens, the case for buying software. Vendors have access to the same AI leverage as buyers, but they start with a stronger foundation: installed customers, mature workflows, integration history, operational edge cases and years of product knowledge. The same is true of strong open-source projects with clear direction and serious maintainers.

But buying is not safe by default. Vendor quality will vary even more than before. Some will use AI to improve implementation speed, deepen product quality and strengthen support. Others will use it to produce flashy demos, shallow features and one-shotted slop. The gap between strong vendors and weak ones is likely to widen, which means build-versus-buy decisions now require more judgment, not less.

That creates two traps in the build-versus-buy decision.

The first is the Dunning-Kruger trap. People see what AI can produce in a prototype and assume they now understand the full system. They mistake code generation for software mastery. They confuse scaffolding with ownership. That is how teams inherit maintenance burdens, hidden edge cases and operational risks they did not know were there.

The second is the opposite failure: the merchants of complexity. These are the people, teams and vendors who benefit from making every problem sound impossibly hard, permanently bespoke and solvable only through long, expensive transformation programmes. Some complexity is real. A pricing engine or underwriting platform is genuinely harder than a planning tool or a simple CRM workflow. But not every hard-looking problem deserves a cathedral. Sometimes complexity is real. Sometimes it is being performed.

That is the discipline this moment requires: neither naive optimism nor learned helplessness.

We should be sceptical of anyone saying AI makes everything trivial. We should also be sceptical of anyone saying nothing meaningful can be built without a three-year programme, a large consultancy and a cast of specialists.

So Should We Build It?

The better question is: what kind of system are we actually dealing with? A simple internal workflow tool is often a good fit. A team can move quickly, learn by doing and avoid a full procurement cycle for something narrow in scope and low in blast radius. In some organisations, the first useful internal version can be live before procurement would have finished the requirements pack.

But the closer a system gets to decisioning, compliance, external integrations and operational risk, the more careful the build-versus-buy decision becomes.

That is especially true in pricing, underwriting and modelling. These are not just interfaces. They are chains of connected systems. Data quality affects model fitting. Model fitting affects simulation. Simulation affects decision-making. Deployment affects live outputs. When something goes wrong, the consequences are not cosmetic. You can end up with broken workflows, poor decisions, compliance exposure, lost margin or customer harm.

AI increases output and compresses iteration cycles, but judgment is still the constraint. The hard part is direction: knowing what to build, what not to build, which edge cases matter, where the real value sits and how the system should evolve over time. If you have more output but no direction, you do not get leverage. You just waste time faster.

That is why the most sensible answer today is often neither pure build nor pure buy. Buy the heavy, repetitive, compliance-laden core. Build the workflow, orchestration and experience layer around it. Use vibe-coding where it creates leverage, not where it quietly signs you up to own complexity you do not actually want.

The question is no longer “can we build it?” It is “do we want to own it?”