AI Is Lowering the Minimum Scale Required for Custom Technology

Custom software has always been expensive to build, and for many businesses that alone ruled it out. But even when the first version was affordable, the continuing cost of understanding, changing and governing it could make ownership uneconomic. AI-assisted development reduces some of the effort of writing code. Its more consequential effect may be on that continuing cost: keeping a system understood well enough to change it responsibly. If that cost falls, the minimum scale at which a business can own tailored technology may fall with it.

That’s a different claim from “AI makes software cheaper,” and the difference matters for anyone deciding what to build, what to buy and what they can realistically look after.

The First Version Was Only the Beginning

Software that people use keeps changing. Meir Lehman put this as the first of his laws of software evolution more than forty years ago: a program in use is changed continually or becomes progressively less useful. Businesses add products, change prices, connect new systems, respond to regulation and rethink how they sell. The software follows, or it holds them back.

Estimates of how much of a system’s lifetime cost goes into this vary widely, depending on what’s counted, and some of the most quoted figures are poorly sourced. The safer observation is that for software in long use, the cost of change is substantial and lasts as long as the system does.

And much of the effort in changing it goes into understanding it first. In one large field study of professional developers, roughly 58% of their working time was spent on program comprehension, inferred from how they used their tools. Before anyone writes a line, someone has to work out what the existing code does, why it does it that way, and what else depends on it.

The build cost kept many smaller organizations away from custom software in the first place. The continuing cost kept many others from owning it well. A tailored system might be affordable to build, while keeping it understood over years of change, through staff turnover and shifting requirements, was not. A platform carried much of that burden on everyone’s behalf, and its constraints were the price.

The Old Discipline Was Sound, and Expensive

None of the principles here are new. When I worked on COBOL applications on mainframes, this was how we approached software development. Written requirements, system specifications, documented design decisions, explicit business rules, testing and controlled change were fundamental to understanding and maintaining complex systems. A well-documented system let a developer who had never seen it understand its purpose, structure and expected behavior.

The decisions are often the hardest part to recover. As Michael Nygard wrote when he proposed architecture decision records, “One of the hardest things to track during the life of a project is the motivation behind certain decisions.” Without that context, the person maintaining the system can either accept a past decision blindly or change it blindly.

The trouble was cost. Documentation took time to write and more time to keep current. Large specifications were hard to read. Documents contradicted each other. The code changed and the documents didn’t. Knowledge still concentrated in a few people, however much was written down.

Agile approaches shifted the balance. The Agile Manifesto valued “working software over comprehensive documentation”, while saying plainly that there is value in the items on the right. It didn’t declare documentation worthless. In practice, though, many organizations wrote much less of it. Sometimes that was the right call. Sometimes it left systems whose reasoning nobody could reconstruct.

I don’t think the answer is a return to the binders. The question is whether the principles behind them can become affordable without the administrative weight that made them hard to sustain.

From Reference Material to Working Input

Traditional documentation was usually a separate deliverable. Developers might consult it. Nothing ensured that later changes respected it, or that it stayed accurate.

AI-assisted development makes a different relationship possible. The knowledge that governs a system includes its requirements and acceptance criteria, architecture, design decisions and their rationale, data structures and dependencies, security boundaries, business rules and test requirements. Kept close to the code, that knowledge can be an input to every change rather than a reference nobody opens.

These records don’t all do the same job. Requirements and business rules define what the system is supposed to do. Implementation documentation describes what it actually does and how. Tests and other verification provide evidence that the two match. They have to stay aligned, because a change that updates one and not the others recreates the old problem of drift. They also have to keep distinct authority. An agent that changed the code, the description of the code and the tests together could make a defective change look entirely consistent. Intended behavior has to be defined somewhere the agent can’t simply rewrite to match what it built, and a change should be accepted against that definition, not against its own account of itself.

A requested change can then start from the relevant requirements and architecture, identify the affected components, update the implementation and tests, and end with the documentation reconciled to what was accepted. An AI development agent can do much of that reading, cross-referencing and drafting, the very tasks that made documentation expensive to keep.

One practical way to protect the separation between intended behavior and implementation is to give a different AI agent responsibility for documentation integrity. Its job would be to examine each change, compare the implementation against the authoritative requirements and the existing architecture, identify dependencies nobody recorded, and flag discrepancies or drift. The development agent makes the change; the reviewing agent checks it; and the requirements both work against aren’t theirs to redefine. Separating the making of a change from the checking of it is an old engineering principle, and AI could make it practical to apply to every change rather than only the important ones. It doesn’t guarantee an independent result. Two agents can share the same mistaken assumption or miss the same defect, so authoritative requirements, evidence from the actual implementation, tests and human judgment still decide whether a change is accepted.

That is the part of this I find most important, and the part most often left out of the conversation about AI coding. The opportunity isn’t only to generate code. It’s to lower the cost of producing, finding, interpreting and maintaining the knowledge that makes code safe to change.

It isn’t automatic, and it isn’t infallible. An agent can misread a requirement, miss a dependency, introduce a defect or write documentation that’s simply wrong. A 2024 study of comments generated by large language models found that, even for the best-performing model, roughly a fifth contained demonstrably inaccurate statements, and that the existing consistency-checking techniques they evaluated couldn’t reliably distinguish accurate comments from inaccurate ones. The researchers proposed checking documentation by generating tests from it and running them. Whatever the method, documentation has to be verified against the implementation, not trusted because it reads well.

There’s a subtler risk as well. Documentation can be internally consistent and still describe the wrong business behavior, which is why authority over intended behavior has to stay with the business, not with any agent.

AI doesn’t create the principles of disciplined engineering. It can make them practical to maintain.

Changing Code Fast Isn’t the Same as Changing It Safely

There are two different speeds here. One is how quickly code can be modified. The other is how quickly a business can make a change it can rely on: one that meets the requirement and doesn’t break something else.

The evidence on the first speed is less settled than the marketing suggests. In a randomized trial by METR, experienced open-source developers working in projects they knew well took 19% longer when allowed to use early-2025 AI tools, while believing afterwards that the tools had made them faster. METR said in early 2026 that developers are probably faster with current tools, but that its newer data was only weak evidence of how much.

The second speed depends on more than the tools. Google’s DORA research, drawing on nearly 5,000 technology professionals, describes AI as an amplifier: it “doesn’t fix a team; it amplifies what’s already there.” The same survey-based report found AI adoption still associated with lower delivery stability. DORA’s interpretation is that without strong automated testing, mature version control and fast feedback loops, a higher volume of change leads to instability. That is an observed association with a plausible explanation, not a proven mechanism, but it points in the same direction as the example below.

Consider a hypothetical regional distributor that needs to change how a delivery surcharge is calculated. The rule appears in the online catalogue, the basket, quotes, order confirmations, invoices and the export to its accounting system.

In one version of its software, the rule lives in a single place, is described in the business rules with its exceptions, and is covered by tests that check each of those outputs. An AI agent can find the rule, change it, update the tests and the description, and the change can be verified across every output it touches.

In another version, the same rule has been copied into templates, adjusted in a plugin, overridden for two large customers and patched once in the export. The agent may write the new code just as quickly. Finding every place the rule lives, and proving that nothing else changed, takes far longer, and the risk of missing one is real.

The AI tools are the same in both cases. Three things differ, and they work together. The architecture determines how many places the rule lives. The maintained requirements and implementation knowledge explain what the rule is meant to do, where its exceptions are and what depends on it. AI reduces the effort of reading that knowledge, making the change and helping to verify it. Take away any one of them and the advantage shrinks. Excellent documentation of a rule copied into six places still leaves six places to change, and a clean architecture that nobody has described still has to be rediscovered before every change.

A business may make dozens or hundreds of changes like this over a system’s life. Lehman’s second law observed that complexity grows as software changes unless work is done to contain it, and maintained documentation and tests are part of that work. Even modest reductions in the cost of each responsible change compound over years, which is why the economics of ownership can shift more than the economics of the first build.

Knowing What’s Installed Isn’t Knowing How It’s Used

To many business owners, WordPress is simply the platform their website runs on. What they may not recognize is that the resulting website should often be regarded as a customized software application in its own right. WordPress is software, PHP code and a database, not merely a publishing interface. Extended with a theme, plugins, integrations, configuration and custom functionality, a particular installation can become a complex, business-specific application. Knowing WordPress well tells you how the platform works. It doesn’t tell you how that installation works: which customizations it has accumulated, what depends on what, which decisions were made along the way and which business rules now live inside it.

Knowing which components are present is still valuable. WordPress’s Site Health screen, for example, shows the active themes and plugins, server setup, database and permissions, and the documentation notes that it only contains information. A software bill of materials does something similar more formally: CISA describes it as “a list of ingredients that make up software components.”

An inventory tells you what’s there. It can’t tell you why a component was introduced, which customizations depend on its behavior, which business functions would break if it were disabled, where its defaults have been overridden, or which tests would show that a replacement works. Those answers live in the implementation. CISA’s related concept, the Vulnerability Exploitability eXchange, exists precisely to state whether a product is actually affected by a known vulnerability, which is a different question from whether a component is present.

This isn’t a criticism of WordPress, and it isn’t a claim that WordPress sites lack documentation. Professionally maintained installations can have excellent records. The same gap exists in undocumented bespoke systems, SaaS integrations and legacy enterprise software.

Security shows why the gap matters. On 21 October 2026, PHP released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical remote code execution vulnerabilities. Earlier releases in those branches were affected, and older, unsupported branches needed a vendor backport or an upgrade. PHP said that “all PHP installations serving web requests” were at risk, that it considered the risk highest in one common server configuration where an exploit had been demonstrated, and that “updating is the only safe choice.” Its interim measures reduced exposure to specific attack paths without making an installation safe. Two days later it followed up with an informational advisory about a related, narrower attack path involving a session feature already named among the original mitigations. This one could only occur under “an unusual combination of configuration and application code”: the application had to change a particular session setting at runtime while that feature was still enabled. Applications that never made that change weren’t exposed to it.

The release range told every site owner whether they were in scope. Actual exposure depended on how PHP was deployed and configured, and for the later issue, on what the application’s own code did. For the two critical vulnerabilities, none of that changed the answer: update. What implementation knowledge adds is the next set of questions. Which interim measures fit this system? What might the update disturb? Which tests will show that everything still works?

None of these disciplines is new. Software bills of materials, dependency inventories, decision records and regression testing all predate AI. What may change is their affordability for an organization without a dedicated engineering team, and whether they become a routine part of every change rather than a project someone means to get to.

Control Becomes Practical, Not Just Possible

Commercial platforms illustrate the trade-offs businesses have accepted. WordPress is highly capable and extensible, and a well-run installation can use shared templates, global styles, reusable components, automated deployment and testing. For many businesses it is the right choice.

But a mature, customized installation accumulates page-specific changes, overrides, plugin interactions and configuration decisions. A global change has to be checked against those exceptions. And some of what the business depends on belongs to third parties, who decide which features get attention, when interfaces change and what gets retired. The business can accept those decisions, work around them, commission an extension or maintain its own fork.

A plugin can be modified in principle. That doesn’t make the modification affordable, maintainable or independent of the next vendor release. The distinction that matters is between theoretical extensibility and the economic practicality of exercising it. The cornerstone of this series argued that AI is making it cheaper to build around a platform’s constraints. The further point is that it may also make it cheaper to own what you build, which is where custom technology has historically failed smaller businesses.

With well-governed custom software, a business can set more of its own development priorities, and AI lowers the cost of acting on them. Dependencies don’t disappear. Frameworks, libraries, hosting and integrations still have owners and release schedules. What changes is which decisions the business can realistically make for itself.

That matters for more than the price of a modification. A business can weigh a new capability against its own priorities, instead of dismissing it because the platform doesn’t support it or the vendor hasn’t put it on the roadmap. Some of those ideas still won’t be worth doing. The difference is that the business gets to decide.

This is where I think the change may matter most. Many organizations running heavily customized WordPress installations have, through years of plugins, overrides and bespoke changes, taken on much of the burden of custom software without the benefits of a system that was deliberately designed, documented and governed. For many of them, replacing that installation with purpose-built technology may offer particularly strong value, and AI-assisted development may change the economics of doing so rather than continuing to work around its constraints. Replacement still isn’t automatically the better choice. Migration, existing functionality, data, integrations and operational risk all have to be weighed, and a well-run installation may serve a business perfectly well.

Architectural choice widens in the same way. For some kinds of website, content can be prepared and the site generated in advance, then served as prebuilt files without running the full content-management application for every public request. The pattern isn’t new, and it doesn’t suit everything: transactions, personalization, authentication and other request-time logic still need server-side processing, and the build chain, dependencies and client-side code carry their own risks. But a business no longer has to accept production complexity simply because it came bundled with the most affordable way to develop and manage the site.

What Doesn’t Change

Commercial platforms keep real advantages: mature functionality, established integrations, vendor-maintained security, compliance features, large communities and predictable subscription costs. Rebuilding standardized functions that are economical to buy is usually waste. The more useful line may run between those functions and the capabilities that matter strategically, where greater control justifies the obligations that come with it.

Those obligations don’t shrink because the code was cheaper. Someone is accountable for correctness, security, availability, documentation, testing, dependencies and long-term support. An organization that can’t hold those responsibilities is often better served by a platform.

AI can also make things worse. Generating code quickly without the governance to verify it is a fast way to build technical debt, and the DORA finding on stability is consistent with that risk. And cheaper change only helps a business that knows what it wants the system to do.

Owning the Discipline, Not Just the Code

The case for custom technology used to depend on scale. A business needed enough budget to build a system, and enough people to keep it understood: to know what it did, why, and what a change would touch.

What may now be falling is not just the cost of producing software, but the cost of the discipline that makes software worth owning. Requirements that stay current, decisions that stay explained, rules that live in one place and tests that prove a change is safe were always good engineering. For many smaller organizations, they were also out of reach.

There is no long-term evidence yet that AI reliably makes that discipline cheaper to sustain. What is changing is the effort involved: AI is reducing some of the work of writing code, and it can assist with maintaining documentation and verifying change, within the accuracy limits described above. Together, those shifts make a lower minimum scale for custom ownership a credible possibility, not an established outcome. Where it holds, it will hold for businesses that keep the discipline, not for those that only buy the speed.