AI & Software’s Next Economic Model Agentic software development is shifting the economic model of the software industry by making custom code variants cheaper to produce, potentially making customisation economically viable for more customers. The traditional model of standardising products to spread development costs is weakening as AI reduces the cost of generating code variants while verification and maintenance costs remain. This evolution suggests successful software companies may focus on the 'factory' level that produces workflows and features rather than on standardised products. Fifty years ago, Fred Brooks sagely noted that there is no silver bullet for good software engineering. Since then, the downstream effect of this axiom for the software industry has been this: to succeed, adapt your business to the product. You might still customise part of a workflow or make cosmetic changes, but largely your core product should remain the same for all your customers. This has played out in consumer software, where millions of people use almost identical applications, as well as in enterprise software where vendors tussle with enterprises to avoid their roadmap getting pulled in different directions. Until recently, there was a good economic reason for standardisation: software was difficult to design, expensive to build and risky to change. Every customer-specific variation had to be not just implemented, but also supported and eventually upgraded; sometimes for years or even decades e.g. core banking software is a good example of the later . Under this model, successful software companies built one -ish product and sold it very many times. They channelled customer needs into a common roadmap, and they pushed towards “product revenue” versus lower margin “services revenue”. In these last fifty years, this model also produced some of the most attractive economics in business history. Development costs were spread across thousands of customers, gross margins vastly improved, and software businesses ballooned in market capitalisation. But, now, the assumptions underneath that economic model are beginning to weaken. Agentic software development is now making software faster and cheaper to produce. PRDs give way to specs, engineers are evolving into agent orchestrators, and coding agents span the SDLC. This does not mean custom software is suddenly free, but it may mean that the “economically optimal” point between standardisation and customisation is shifting. As a result, the next wave of successful software companies may be those that don’t focus at the level of workflows and features, but at the “factory” level that produces them. To explore this evolution, we could start by separating the cost of producing a code variant from the cost of “owning it” over time . This should make instintive sense as AI may make code generation much cheaper, while verification, support and accountability do not go away. 1. The core before-and-after formulas Traditional customised software Where: Agentic, specification-driven software The last term is the reason traditional customisation becomes painful. Ten customer variants do not necessarily create ten times the difficulty. They may create twenty or fifty times the organisational complexity. Agentic, spec-driven software Where: The economic promise is not merely that α becomes large. It is that good architecture, specifications and automated testing also make: In summary then, each additional variant becomes cheaper to create, while the total system remains manageable as the number of variants grows. 2. The customisation viability formula For an individual customer, customisation makes economic sense when its additional value exceeds its full lifecycle cost: The value created can be written as: Where: Historically: Therefore, the rational answer was usually to standardise. In the agentic model however: That means customisation can become economically attractive without requiring an extremely high customer price. Customisation becomes viable when the additional customer value created by better fit exceeds the full cost of specifying, generating, verifying and maintaining the variation. 3. The Customisation Frontier With those building blocks in mind, we could use this simple ratio of a “Customisation Frontier” CF for the related trade-offs, based on the idea of Production Possibility Frontiers from micro-economics. Where: Historically: Whereas in the Agentic model: The Customisation Frontier therefore is the point at which the value of fitting the software more closely to the customer becomes greater than the lifetime cost of supporting that variation; Agentic development moves that frontier. 4. The automation-adjusted lifecycle-cost formula To go a step further and make this more nuanced, we could then reflect how Agentic development does not impact the SDLC uniformly. Where: Today, the likely relationship is: since the industry is better at automating the creation of code than proving that it is correct or maintaining it for years. If, for example, AI reduces generation cost by 80% but reduces verification and maintenance cost by only 10%, the overall economics of custom software improve much less than coding demos would suggest at face-value. Over time, the model becomes transformative only if: That is, if verification, regeneration and maintenance become more automated alongside implementation. 5. Standard product versus traditional custom versus Agentic custom A comparison formula could illustrate the three models. a. Standard SaaS The fixed product-development cost is spread across many customers. b. Traditional custom software c. Agentic custom software The core economic change is that: The strategic question, and the real test, is whether the following can also become true: vs. simply an agent writing a first version faster. 6. Gross-margin formula To tie this concept back to product-company economics, we can use Gross Margin GM : Traditional customisation damages margin because: and the Agentic thesis is: A customer-specific product can improve price, adoption and retention while adding relatively little marginal engineering cost. You could illustrate the margin effect as: If the fit premium exceeds the residual cost of variation, customisation improves rather than erodes margin. 7. A simple numerical illustration Let’s try it with some numbers We’ll assume a customer-specific workflow creates $200,000 of additional three-year gross profit through higher pricing, adoption and retention. a. Traditional model Therefore: and the vendor should resist the customisation. b. Agentic model Therefore: and the same customer-specific feature has crossed the customisation frontier. The key point here is that generation has not suddenly become free; it’s the total lifetime economics that have moved from negative to positive. 9. Simple summary formula Historically: Therefore answer was: Whereas in the emerging Agentic model: Therefore: Any serious argument about a transformation in software engineering eventually goes back to Fred Brooks. In The Mythical Man-Month , Brooks explained why adding more programmers to a late software project could make it later , and that software development is not a simple production line but a coordination-intensive intellectual activity. He noted that as teams grow, communication and integration costs grow with them. In “No Silver Bullet,” he then made an even deeper distinction between “accidental” and “essential” complexity: All in all, AI is can enable software companies to seriously expand their Customisation Frontier. Just as Steam power did not eliminate the complexity of manufacturing, but it did change what could be manufactured, in what volume and at what cost, Agentic development could do something similar for software. Take the example of a banking platform. The same transaction model. The same security controls. The same audit framework. The same deployment infrastructure. The same integration contracts. But the operating workflows could be generated around the needs of each bank. Approval rules could reflect its authority model. Exception handling could match its organisation. Terminology could mirror the language employees actually use. Regulatory requirements could vary by jurisdiction. User interfaces could be adapted to different roles. The system would not become a separate handmade product for every bank. It would become a family of related implementations produced within a vendor-governed platform. For a more extreme example, we could apply this thinking to B2C software: If this model develops, product management as a discipline develops with it. Product managers will spend less time deciding whether every customer receives a particular feature and more time defining the boundaries of the product family: Which capabilities are universal? Which behaviours may vary? What are the invariants? Where should customers have control? Which recurring requests should move into the shared core? Software engineering changes too: engineers still write code, particularly for foundational components and complex systems. But more effort moves toward designing constraints, agent environments, evaluation systems or recovery mechanisms. Quality engineering especially, becomes more important, as when software can take many forms, testing a single known application is no longer enough; teams need to validate a family of possible outputs. The overall company model was simple: Build one product and sell it many times. The emerging model may be different: Build one reliable software factory and use it to produce many related products. As the lifetime cost of variation falls the Customisation Frontier moves, and this new breed of software companies standardise the factory , while daring to customise the software. Further reading & links 2. Parnas, D. L. 1976 . “ On the Design and Development of Program Families. https://ieeexplore.ieee.org/document/1702332 ” 3. Pine, B. J. II. 1993 . Mass Customization . 4. GitHub. 2025 . Spec Kit . 5. Becker et al. 2025 . “ Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ ” AI & Software’s Next Economic Model https://pub.towardsai.net/ai-softwares-next-economic-model-a0ace46bbf0a was originally published in Towards AI https://pub.towardsai.net on Medium, where people are continuing the conversation by highlighting and responding to this story.