AI software’s customisation frontier is moving

The economics of software customisation may be changing because agentic development lowers the cost of producing code variants. In a recent Towards AI analysis, Yannis Perrakis argues that the decisive question is not whether an AI coding agent can produce a first version quickly, but whether a governed system can keep many variants reliable over time. For software operators, the takeaway is practical: measure the lifetime cost of ownership before moving from a standard product to customer-specific software.

Definition: The customisation frontier is the point where a software variation creates more customer value than its full lifecycle cost.

Example: A banking platform could keep shared security, transactions and audit foundations while generating different approval workflows for each bank.

Key takeaway: Agentic development may make variation cheaper, but verification, support and accountability still determine whether it pays.

Business impact: Software companies may compete by standardising the factory that produces software while customising the products that factory delivers.

Why did standard software win?

Standardised software became the dominant economic model because software variation used to create long-lived ownership costs. Before agentic development, a customer-specific feature had to be designed, implemented, supported and upgraded, often while the vendor maintained a growing set of divergent versions. That history explains why software companies pushed common roadmaps and product revenue; operators evaluating custom work should count the support tail, not only the implementation estimate.

A standard product also spreads fixed development cost across many customers. Consumer applications can serve millions of people with largely shared behaviour, while enterprise vendors try to keep customer requests inside one maintainable product line. This model improved gross margins when the cost of building a common core could be distributed widely, so a custom request had to justify the extra operational burden before it was accepted.

The existing build-versus-buy decision for AI agents uses the same principle at workflow level: buy or configure commodity capability, then own the layer where the business value is genuinely specific. The new question is whether agentic development changes how much of that specific layer a vendor can economically produce and maintain.

What changes with agentic development?

Agentic development shifts the cost debate from writing code to managing a family of outputs. Perrakis describes a model in which product requirements become more specification-driven, engineers spend more time orchestrating coding agents, and agents span more of the software-development lifecycle. For a software company, the opportunity is lower marginal production cost; the required response is stronger architecture, specifications, testing and operational ownership.

The important distinction is production cost versus ownership cost. Code generation may become cheaper without making verification, support or accountability disappear. That distinction matters because ten customer variants can create more than ten units of organisational complexity when each variant interacts with releases, incidents, permissions and upgrades. Teams considering customisation should therefore model every variant as a living system, not as a one-time code-generation task.

The broader AI automation stack makes the same systems point: a model is only one layer, while orchestration, tools, guardrails and monitoring determine whether an automated workflow can operate safely. Agentic custom software adds another requirement—the factory must validate a range of possible outputs instead of testing only one known application.

When does custom software become viable?

Custom software becomes economically viable when the additional customer value exceeds the variation’s total lifecycle cost. The value can come from a closer workflow fit, higher adoption, stronger retention or a price premium, while the cost includes specifying, generating, verifying, supporting and maintaining the variation. This gives operators a concrete test: approve custom work only when the incremental value is larger than the full cost of owning it.

The customisation frontier moves only when the full system improves, not when code generation alone gets faster. The source gives an illustrative contrast: if AI reduced generation cost by 80% but verification and maintenance cost by only 10%, the total economics would improve far less than a coding demo suggests. That is a useful operating warning: measure the completed, supported workflow rather than the speed of the first commit.

What could a software factory produce?

A software factory could keep a reliable platform core while generating bounded customer-specific workflows. The source uses a banking platform as an example: transaction models, security controls, audit frameworks, deployment infrastructure and integration contracts can remain shared, while approval rules, exception handling, terminology, role-based interfaces and jurisdiction-specific requirements vary. The practical design target is a governed family of implementations, not an unrelated handmade product for every customer.

A software factory changes the product boundary from features to invariants. Product teams would need to define what every implementation must preserve, what customers may control, which behaviours can vary, and which repeated requests belong in the shared core. Software teams would still build foundational components, but more effort would move toward constraints, agent environments, evaluation systems and recovery mechanisms.

This model also has a consumer-side implication. The source argues that consumer software could move beyond personalising content or recommendations toward personalising workflows, automations and feature combinations. That possibility is still a direction of travel, not a proven market outcome; businesses should treat it as a hypothesis to test rather than assume that every user needs a separate application.

What does the model not solve?

Agentic development does not remove essential software complexity. Fred Brooks’s distinction, as presented in the source, separates accidental complexity such as syntax and implementation details from essential complexity such as conflicting requirements, business rules and decisions about what a system should do. Coding agents can reduce work in the first category, but a software factory still needs people to define the second category and judge whether the result is correct.

A cheaper first version does not prove a profitable software business. A variant can still fail because its requirements are ambiguous, its tests are weak, its data changes, its permissions are wrong or no team owns the support path. The source’s economic thesis therefore depends on automating verification, regeneration and maintenance alongside implementation; without those controls, a factory may simply produce more software that costs more to own.

What should software operators watch next?

Software operators should watch the ratio between variant value and lifecycle cost, not agent-generated code volume. The useful evidence will be whether a factory can repeatedly produce customer-specific behaviour with stable quality, bounded support effort and acceptable margins. A pilot should track specification time, generation cost, verification failures, human review, incidents, maintenance work and customer outcomes before the company changes its product strategy.

The likely strategic split is between companies that standardise products and companies that standardise production systems. Standard SaaS will remain attractive where workflows are common and shared delivery is efficient. Agentic custom software will become more compelling where workflow fit creates enough value to pay for ownership. The unresolved question is not whether software can be customised, but how much variation a company can govern before the factory itself becomes the bottleneck.

The news is therefore less about the end of SaaS than about a possible change in where software economics concentrate. If agentic development makes specification, testing and regeneration reliable at scale, the reusable asset may be the software factory. If it only makes the first draft faster, standardisation remains the safer business model.