For years, the sensible default in software was to buy. Building an internal system meant assembling a team, waiting months for a first version, and accepting a long tail of maintenance. A vendor could spread those costs across many customers. Even an imperfect product often won because the alternative was an expensive commitment with no clear end.
Coding agents are changing that calculation. They make the first version cheaper, but that is only the obvious part. They also absorb much of the repetitive work that made custom software unattractive after launch: upgrading dependencies, tracing failures, extending test coverage, updating integrations, migrating schemas, and making small changes that never quite reached the top of an engineering backlog.
The result is not that every company should build everything. Payroll, email, and commodity accounting software are still usually better bought. The change is more specific and more consequential: the threshold at which building becomes rational has moved. Software that once needed to be a major strategic advantage to justify custom development may now only need to fit the operation materially better.
The old equation favored vendors
The traditional build-versus-buy analysis compared a visible subscription price with a large and uncertain internal cost. Building required product managers, designers, engineers, infrastructure, support, and a willingness to carry the system for years. Buying offered a working product, known pricing, and somebody else to call when it broke.
Maintenance was usually the decisive argument. A prototype could be built quickly, but production software had to survive changing requirements, staff turnover, security reviews, dependency upgrades, and integrations that drifted over time. The first version was a fraction of the true cost. Keeping it useful was the commitment.
The strongest argument for buying software was rarely the cost of version one. It was the cost of versions two through twenty.
Vendors also had economies of scale. One engineering team could solve the same problem for thousands of customers. An internal team could not compete with that cost structure, especially when it had to divide its attention across many systems.
Agents compress the lifecycle, not just the build
Most discussion about coding agents focuses on generation: describe a feature and get code back. That matters, but it understates the economic shift. The larger gain comes from applying agents across the full life of the system.
An agent can inspect an unfamiliar codebase, follow a failure across services, make a bounded change, run the checks, and document what changed. It can repeat the process without becoming bored by the fourth dependency update or the twentieth variation of a data migration. Work that was important but uneconomical now has a much lower marginal cost.
This does not make maintenance disappear. Someone still has to define the intended behavior, choose the architecture, set constraints, review risky changes, and decide whether the system is worth keeping. Agents can do the grunt work relentlessly. They cannot decide what the operation should become. Human attention moves away from typing and ticket throughput toward judgment, verification, and direction.
That distinction matters. If the only improvement were faster feature development, custom software would still accumulate into an unaffordable estate. When the same agents that build the system can also inspect, repair, test, refactor, and migrate it, the long-term cost curve changes.
Custom software can preserve the shape of the operation
Bought software comes with a data model and a view of how work should happen. At first, the compromises seem small. A customer becomes an account because that is the object the product supports. A review becomes a ticket. An exception becomes a note in a text field. Over time, the company bends its operation around the vendor's abstractions.
This is acceptable for commodity processes. It is costly where the process contains the company's judgment. The unusual approval path, the way evidence is linked to a decision, or the distinction between two seemingly similar customer states may be the operation itself. Flattening those details into a generic product can make the system easier to buy and the business harder to run.
Cheaper custom development makes it practical to encode the actual operation. The software can use the company's language, represent its exceptions directly, and evolve when the process changes. The aim is not novelty. It is fidelity.
The decision needs a new set of questions
The old checklist still matters, but the weights have changed. I would now ask:
- Is the process differentiating? If the workflow expresses how the company creates value or applies judgment, fidelity may matter more than feature count.
- How much adaptation does the vendor require? A cheap product becomes expensive when people maintain spreadsheets, manual handoffs, and shadow systems around it.
- Can the behavior be verified? Agents lower implementation cost only when tests, observability, and review boundaries make their changes safe to accept.
- What is genuinely commodity? Build the part that carries unique context and buy the parts where standardization is an advantage.
That last question often leads to a hybrid architecture. A company might buy identity, payments, messaging, and infrastructure while building the workflow that joins them. Coding agents make the custom layer thinner and cheaper to maintain. Open standards and clear boundaries keep the bought components replaceable.
Ownership has to be earned
Cheap code can create a new kind of waste. If every team generates its own application without shared architecture, tests, observability, or lifecycle rules, the company has not escaped SaaS sprawl. It has replaced it with codebase sprawl.
The bar for building should therefore fall only when the operating discipline rises. Repositories need explicit constraints. Important behavior needs executable checks. Data models need owners. Security and compliance cannot be left to a plausible-looking generated diff. Agents make this discipline cheaper to apply, but someone still has to design it.
The strategic shift is not from buying everything to building everything. It is from treating custom software as a scarce capital project to treating it as a continuously maintained expression of the business. When agents can do much of the production and upkeep, software does not need to be a once-in-a-decade strategic advantage to justify building it. A materially better fit may be enough.
Ownership also changes who controls the data and context created by the operation. That has its own economics, especially when agents depend on that context to work well. I continue that argument in The Data Sovereignty Flywheel.