Published July 28-August 2, 2026
1
Thirty-Five Years Ago
Some essays begin with an idea. This one begins with a memory.
While gathering my thoughts for this series, an old book surfaced from thirty-five years back: Michael Cusumano’s Japan’s Software Factories: A Challenge to U.S. Management, published in 1991. Japan had just spent two decades stunning the world in automobiles, machine tools, semiconductors and computer hardware — winning not on cheap labour but on production systems that delivered quality, variety and relentless improvement at once. Cusumano documented what happened when Hitachi, Toshiba, NEC and Fujitsu turned that same industrial ambition on code itself: the deliberate evolution, as he put it, from “craft to factory modes of software production.”
The factories rested on three pillars. Modules were designed for reuse across projects, so programs were not built from scratch. Development followed strict, standardised phases rather than individual heroics. And statistical quality control — the discipline of the Toyota line — was applied to defects, producing failure rates American software houses could not approach. Treat code as manufacture, the thesis ran, and software would yield to industry the way cars had.
The book found me at a susceptible moment. In mid-1992 I returned to India to begin my entrepreneurial journey, carrying the dream of building software products from India. I tried a multimedia database. I tried an image-processing workbench. Both failed. And with them, quietly, died my dream of building a software factory from India.
But the phrase never left me. Software factory. Every few years it resurfaces and asks the same two questions: how do you industrialise the creation of software — and what would it take for India to build such factories?
For over three decades, the honest answer to the first question was: you cannot, not fully. The Japanese factories succeeded at exactly what they controlled — process, reuse, quality — and still did not conquer software, because everything they industrialised was arranged around the programmer, while the programmer remained the unit of production. Process discipline could polish the craft. It could not replace the craftsman. Japan proved the ambition was right and the technology was missing.
Thirty-five years later, the missing piece has arrived. This essay is that old idea, returned — with the one thing it always lacked.
**
Here is the strange thing about the industry Cusumano was studying. Software went on to industrialise everyone else — factories, supply chains, finance, commerce — but its own creation remained artisanal, exactly as he found it. It is still made by teams of highly skilled people working for months or years to turn requirements into designs, designs into code, code into tested products, and products into reliable services. The cloud transformed how software was distributed. It did not transform how software was created.
Artificial intelligence is beginning to do exactly that — and the result could be the third great affordability revolution of the modern era. China transformed the economics of physical products. India transformed the economics of technology services. AI can now transform the economics of the finished software product itself.
The vehicle will be the software foundry — Cusumano’s factory, rebuilt around the ingredient it never had: a production system that uses AI not simply to help programmers write code faster, but to manufacture focused, reliable, affordable software products, repeatedly. Its promise is not every feature for every possible customer. Its promise is more useful than that: identify the 10–20% of features that carry 80–90% of the customer’s utility — and deliver that utility at 10–20% of today’s price.
This is not merely cheaper software. It is the beginning of software abundance.
2
The Last Artisanal Industry
Almost every important industry has made the journey from craft to industrial production. Textiles moved from handlooms to mechanised mills. Automobiles moved from workshops to assembly lines. Consumer goods moved from local workshops to globally integrated factories. In each case, something that had been made expensively by skilled hands became something made systematically at a fraction of the price — and the world got far more of it.
Software helped make many of those transitions possible. Yet software creation itself remained stubbornly dependent on craft. A serious software product has traditionally required a large and varied team: product managers to define what should be built, designers to shape how it works, engineers to write the code, testers to find defects, security specialists to protect it, infrastructure teams to operate it, consultants to implement it and support staff to help customers use it. Seventy years into the computer era, the production process would still be recognisable to a programmer from 1985.
Four production lines. Three found their factory. The fourth is the opportunity.
It is not that nobody tried. Higher-level languages reduced how much code humans had to write. Reusable libraries stopped every developer rebuilding common functions. Offshoring moved work to lower-cost locations. Low-code platforms let predefined applications be assembled faster. Open source gave builders components created by a worldwide community. All of these mattered. None removed the central constraint. A skilled human still had to understand what was needed, translate it into software, connect the parts, test the result, diagnose its failures and maintain it over time. The craftsman acquired better tools — but the production system still revolved around the craftsman. The bottleneck survived every assault, and so did the prices built on it.
The cloud then created a second, more subtle paradox: it industrialised software’s distribution without industrialising its creation. Before the cloud, software was packaged, installed and upgraded separately for each customer. SaaS replaced that with one centrally operated product delivered over the internet; the marginal cost of another user became almost nothing. By every rule of economics, prices should have collapsed. Instead they went up. Providers learned that software could be priced on customer value rather than production cost. Perpetual licences became subscriptions; subscriptions became per-user plans; plans became bundles, editions, add-ons and usage charges; annual increases became normal. The industry achieved factory-scale distribution of handmade goods — at handmade prices.
The paradox at the heart of the software industry.
Meanwhile the products themselves kept expanding. Every new customer segment brought requests for more controls, more integrations, more reports, more configuration. Features accumulated like geological layers; the product became a suite, and the suite became a platform. This expansion was not entirely wasteful — large, complex customers do need sophisticated capabilities. But a structural imbalance emerged: the product was designed for the totality of customer requirements, while each individual customer used only a fraction of it. A company might rely on a handful of workflows, reports and integrations, yet pay for hundreds of capabilities it never touches. A smaller company might reject the product altogether as too expensive and too complicated. Software achieved abundance in features — but not affordability in outcomes.
AI coding agents are the first technology in the industry’s history that changes the production function itself. Today’s agents can inspect a codebase, write features, generate tests, diagnose bugs, produce documentation and run many tasks in parallel; Anthropic’s own research on how its coding agent is used found that the large majority of interactions were automation rather than assistance — the agent doing the work, not helping a human do it. These remain evolving tools, and complex software still demands human architecture, judgement and governance. But the direction is unmistakable: more and more of the production process can be delegated to machines.
The significance is much larger than programmer productivity. A programmer becoming thirty per cent faster improves the economics of the existing software company. A small team directing a collection of agents to produce, test and operate many applications changes the nature of the company itself. The unit of production shifts from human hours to a system: specifications, agents, reusable components, tests and quality controls. Software begins to move from workshop to foundry.
That distinction is the essential one. A workshop produces one application through concentrated craftsmanship. A foundry creates a repeatable process through which many applications are produced. The foundry does not eliminate human expertise; it elevates it. Humans specify the problem, set the architectural principles, define the quality standards, inspect the exceptions and take responsibility for consequential decisions. AI performs a growing share of the construction, testing, documentation and maintenance.
Markets have already sensed the shift: the great software sell-off of early 2026 — a trillion dollars of SaaS market value repriced in weeks — was the sound of investors realising that per-seat pricing and feature-count value propositions sit on a foundation that is dissolving. But a sell-off is only demolition. The construction is what matters, and it has a precise threshold: The industrial revolution in software will not arrive when AI writes all the code. It will arrive when the tenth reliable application is materially cheaper and faster to produce than the first. That is the line between better tools and a new industry.
3
The Wedge and the Moat
It is tempting to describe China’s manufacturing advantage and India’s services advantage as stories of cheap labour. That description misses the central lesson of both. Lower cost was the opening. The enduring advantage came from the production system built around it.
China did not become the world’s manufacturing centre merely because wages were lower; plenty of places had low wages. It built dense supplier networks, specialised industrial clusters, tooling expertise, logistics infrastructure, quality systems and a culture of rapid, cumulative cost reduction. A designer could move from prototype to components, assembly, packaging and shipment through an ecosystem that grew more capable as more production entered it. The advantage compounded even as wages rose — which is how you know the wages were never the point. Western manufacturers learned to speak of “the China price” as a noun: not a cheap factory quote, but an integrated production capability that established players could not match without dismantling their own economics.
India’s information-technology revolution followed the same arc. Lower-cost engineering talent was the wedge. The lasting invention was the delivery machine: work decomposed across locations, offshore and onsite coordination, codified processes audited to maturity levels the clients themselves could not pass, talent pyramids, training engines that turned hundreds of thousands of graduates a year into deployable engineers. Global corporations did not send work to India because Indians were inexpensive. They sent it because Indian firms had industrialised the process of delivering technology services reliably at scale. The wage gap opened the door; the delivery machine kept it open for three decades.
The pattern, stated once: in every affordability revolution, the cost input is the wedge and the production system is the moat. Cheap labour won China the first order; the factory system won it the next ten thousand. Cheap engineers won India the first contract; the delivery machine built an industry.
Three revolutions, one pattern: the cost input opens the door; the production system keeps it open.
Now apply the pattern to AI — and confront the obvious objection directly. If AI makes software cheap for one entrant, will it not make software cheap for everyone? It will make code cheaper for everyone. It will not automatically give anyone a foundry. The same objection could have been raised against China and India: industrial equipment was purchasable anywhere, and talent was mobile. Yet particular regions and companies built compounding advantages by organising those inputs better than anyone else. AI-generated code is the ore, not the product. Whoever merely uses the coding models holds a discount that expires the moment competitors log in. Whoever industrialises them builds the third great production system.
What does industrialising look like? A foundry does not create every component from first principles; it combines common machinery, standard processes and reusable materials to produce many finished products. In software terms: identity and permissions built once; workflow engines, connectors, data management, notifications, billing, audit, analytics, backup and recovery built once — so that each new product is mostly a domain model, a set of screens or conversational flows, and configuration on shared foundations. The first product may take substantial human effort. The fifth should reuse the machinery of the first four. The twentieth should inherit a library of proven patterns and quality checks. A conventional software company organises itself around one product that gradually expands; a foundry organises itself around the repeated act of production. It is the difference between building a machine and building the machine that makes machines. If every product requires an entirely new architecture, it is not a foundry. It is traditional IT services using AI-generated code.
Industrialising quality, not just speed
This is also why “AI makes coding cheaper” is an incomplete argument — and where the naive version of this thesis dies. If every application is independently generated, independently tested and independently supported, the apparent productivity gain disappears into inconsistency, technical debt and maintenance. Rapidly generated code produces fragile products when nobody understands their architecture or verifies their behaviour. A flood of brittle, insecure AI-built software would raise customer costs, not lower them.
Manufacturing did not become dependable because machines produced parts quickly. It became dependable through specifications, tolerances, inspection, statistical quality control and traceability. The software foundry needs the equivalents: machine-readable specifications that agents can execute well; automated tests as the default, not the afterthought; security policies and architecture rules enforced by the production system itself; versioned components; behavioural monitoring; failure replay and rollback; human approval reserved for high-risk changes. The foundry must industrialise quality as aggressively as it industrialises speed. The objective is not maximum code generation. It is maximum reliable utility per unit of cost.
Do this well, and something larger happens than one company’s cost advantage. A new reference price forms — a foundry price — just as previous production systems established new reference prices for goods and services. Once customers know that focused, reliable software can be delivered for a fraction of the traditional price, the old price becomes harder to defend everywhere. That is how a productivity tool becomes a market revolution.
4
Generic Software and the Double Pareto Cut
There is a second Indian precedent that illuminates the coming transformation even more precisely than services: generic medicine.
A medicine can be extraordinarily valuable and still unaffordable to most of the people who need it. For decades, life-saving molecules were priced at thousands of dollars a year. Then Indian pharmaceutical companies mastered the chemistry, industrialised the production and sold the same therapeutic value for a dollar a day. The result was not merely savings for existing buyers — it was access. Treatments moved from wealthy markets to millions of people who previously had none. Generics did not shrink medicine. They took medicine to a billion people.
Software has the same access problem. Large companies can afford sophisticated systems, implementation partners, specialist administrators and long deployments. Smaller businesses cannot — so they run important processes through spreadsheets, email threads, messaging groups and human memory. They do not lack the need for better software. They lack software whose price, complexity and operating requirements match their reality.
Software is now getting its generics moment, with one twist that makes it faster and stranger than pharma’s. In medicine, generic manufacturers had to wait: the patent protected the incumbent for twenty years. In software there is no patent to wait out — because the real protection was never chiefly legal. The patent was always the cost of writing the code. Rebuilding a mature product meant years of engineering and tens of millions of dollars, so nobody did it, and prices stood. AI has just expired that patent — for every product, in every category, simultaneously. (The analogy is not exact: copyright, trade secrets, proprietary data, brands and contracts still protect software in ways no molecule enjoys. But the tallest wall — the economic barrier built from years of engineering effort — is the one that fell.) Generic software is not arriving molecule by molecule over decades. It is arriving all at once.
The double cut
Generic software must not mean copying the incumbent feature-for-feature — that would recreate the incumbent’s complexity and cost, and with them its price. The foundry’s second principle begins with a distinction the software industry has spent decades blurring: a feature list is the seller’s view of software; utility is the customer’s view. Customers do not buy software because they admire the number of menu items. They buy it to complete jobs: capture information, coordinate work, serve customers, approve requests, analyse performance, send communications, keep records. The traditional software company pursues completeness — every feature any customer might ever request, accumulated over twenty years of enterprise deals. The foundry pursues sufficiency — the smallest coherent product that performs the customer’s jobs reliably.
The double cut: a small share of features carries most of the utility — and can be delivered at a fraction of the price.
Examine any mature business application and the same imbalance appears: a small share of the features — perhaps ten to twenty per cent — carries eighty to ninety per cent of the daily utility for a given kind of customer: the workflows people run daily, the records they keep, the reports they read, the alerts they act on. The remaining features exist for someone, somewhere, occasionally; yet every customer pays for all of it. So the foundry cuts twice. The first cut is on utility: identify the vital few features that carry nearly all the value for a clearly defined customer. The second cut is on price: because the focused product avoids the long tail, simplifies configuration, sits on a shared production system and operates through AI-native support, it can be delivered at ten to twenty per cent of the incumbent price. The customer does not lose most of the product. The customer loses most of the bloat.
This is why the proposition is not “cheap software” — cheap implies compromise. It is: the software you actually use, without paying for the software you do not. Not “all the same features, copied more cheaply”, but most of the useful outcome, deliberately rebuilt for a new cost era.
Why the incumbents cannot follow
Here is the uncomfortable truth about why the bloat exists at all: feature accumulation is not an engineering accident; it is the pricing model. Feature breadth creates editions, tiers, bundles and reasons for annual expansion. More capabilities support higher prices; higher prices support large sales, implementation and customer-success organisations; those organisations require continuing revenue growth, which demands more features to sell. Over time the loop closes: the software becomes expensive partly because it is comprehensive, and it becomes comprehensive partly because it must remain expensive.
Which creates the incumbent’s dilemma. A mature software provider has every technical capability required to build a simpler, cheaper version of its own product. What it does not have is permission. Its valuation rests on net revenue retention — the expectation that every existing customer pays more next year than this year. A suite vendor that matched the foundry price would cannibalise its contracts, collapse its revenue per customer and destroy its own share price long before it destroyed any challenger. The entrant carries no such burden: it starts with the new cost structure, the narrow product and the low price, with no yesterday to protect. It is precisely the trap that caught Western manufacturers against the China price — the incumbent could see the number and could not afford to say it.
Price is necessary; trust is sufficient
One honest caveat closes this part, because the argument fails without it. Code is not the whole cost, and price alone will not win. A business choosing software does not only ask whether the features work. It asks: will my data transfer safely? Will it connect to everything else? Can my people learn it? Will it still exist in three years? Who answers when something breaks? The incumbent’s deepest moat was never the code — it is the customer’s fear of migration.
Generic medicines succeeded because patients could trust that the affordable pill still performed its essential job — and that trust took cold chains, pharmacies and regulation, not just cheap chemistry. Generic software needs its own trust architecture: dependable operation, data portability, security, compatibility, continuity. The affordable product must never feel disposable. A true software foundry is therefore a migration factory as much as a code factory: it makes moving data, users, permissions and integrations predictable; it lets the new run beside the old until trust is earned; and it rebuilds support itself around AI — products that diagnose their own problems, documentation that updates as the product changes, human experts reserved for the moments that need judgement. A workshop can make a cheap copy. Only a foundry can make consistent output — and consistency, not cheapness, is what converts a curious customer into a switched one.
5
The Affordability Dividend
What happens to a market when its product suddenly costs one-tenth as much? The instinctive answer — the market shrinks to a tenth of its revenue — has been wrong every time in economic history. When the steam engine made coal-powered work cheaper, coal consumption exploded; economists call it the Jevons effect. Cheaper computing did not reduce the market for computing; it put computers into offices, homes, pockets, cars, factories and appliances. Cheaper communication expanded from occasional long-distance calls into continuous messaging, video and data. Cheaper manufactured goods did not merely save money for existing consumers — they created new classes of consumers altogether. Cheaper software will not mean a smaller software industry. It will mean software used by ten times as many businesses, for ten times as many jobs.
Because the greatest effect of the foundry will not be on the businesses that switch. It will be on the businesses that start. Today a large enterprise may run hundreds of software products; a small company a handful; a local business almost none beyond basic accounting and messaging. That difference is not explained by need. Small organisations also have customers to manage, work to coordinate, employees to support, decisions to make and data to understand. They are simply priced out — over-served by enterprise suites built for companies a hundred times their size. At one-tenth of today’s price, the addressable market changes shape, and the relevant question is no longer how much revenue moves from expensive software to cheaper software. It becomes: how many businesses will use serious software for the first time?
Five layers of the dividend
The affordability dividend arrives in layers. Direct savings: existing customers cut the cost of common software and redirect the money towards people, products or growth. Wider adoption: businesses previously priced out begin to use sophisticated tools. Specialisation: when software is cheap to produce, smaller professions, industries and workflows get products designed specifically for them — the market no longer needs millions of potential users before an application makes economic sense. Experimentation: a company can try a new process without a large contract or a multi-year implementation, and more experiments mean more learning. Local adaptation: affordable software can be built for different languages, regulations and business practices, rather than forcing every customer into a product designed for the world’s largest companies.
Follow those layers far enough and the software foundry stops being a software-industry thesis and becomes an economic-development thesis. The school managing admissions on a spreadsheet gets an admissions system. The clinic scheduling patients through a messaging group gets patient workflows. The twenty-person manufacturer gets production planning; the retailer gets inventory intelligence; the professional firm automates its repetitive operations. Each improvement is modest. Across millions of businesses that largely missed every earlier wave of digitisation, the aggregate is not. A business should not need to become large before it deserves excellent technology — any more than a patient should need to be rich before deserving effective medicine. Software is becoming infrastructure, and infrastructure is judged by who it reaches.
Every product makes the next one cheaper; every price cut makes the market larger.
The two worlds of software
None of this means all software converges to a tenth of its price. When creation becomes abundant, value does not vanish — it moves. Some software will remain expensive for reasons no foundry can touch: network effects, irreplaceable proprietary data, regulatory depth, deep customisation, mission-critical reliability, trust accumulated over decades, outcomes measured and underwritten. That world is safe, and deserves to be. What gets exposed is the vast middle: mature categories with bloated feature sets, thin daily use, per-seat prices long decoupled from cost, and no remaining differentiation except the customer’s fear of leaving. The foundry does not attack the first world. It liberates the second.
Value beyond the code stays protected; price held up by switching cost alone gets exposed.
India’s product moment
And there is a particular opportunity here for India — perhaps the largest since the services revolution itself. Indian IT gave the country revenue, employment and global credibility, but it never gave India products: the model sold engineering hours, and the intellectual property stayed with the client. There was a good reason. Building software products used to be a craft-intensive, capital-intensive game — the Valley’s game, requiring dense pools of elite product talent and patient venture capital. The foundry changes the nature of the game: product-building becomes process-intensive and cost-intensive — and process and cost are precisely the games India has spent forty years winning.
Consider what the foundry needs. The hardest part of useful business software was never the screen or the database function. It is knowing how organisations work: where the data comes from, which approvals matter, which exceptions break the process, why implementations fail, what users do when the official workflow jams. India’s technology industry has spent decades — and a million enterprise projects — acquiring exactly that knowledge, and until now could only rent it out by the hour. AI creates the way to productise it. A small team can combine domain knowledge, coding agents and a shared production system to build software for a worldwide market — designed for affordability from the beginning, rather than built for wealthy enterprises and cut down for everyone else. It is the transition from exporting hours to exporting products — and it can draw on both of India’s great traditions at once: the process discipline of its services industry and the affordability ambition of its pharmaceutical industry. China became the factory of the physical world. India can become the foundry of the software world.
The opportunity is not automatic. AI-generated software can just as easily produce a flood of brittle, insecure, unmaintained products — cheap creation without quality discipline raises customer cost rather than lowering it, and the last ten per cent of engineering (reliability, security, migration, edge cases, long-term maintenance) may remain the hardest part. So the foundry must reject the idea that speed alone is the revolution. The real objective is trusted affordability: software that is inexpensive because its production and operating systems are structurally more efficient — not because quality, security and responsibility have been removed. The best foundries will pair machine speed with human accountability, knowing which parts can be fully automated, which require verification and which must stay under direct human control. Their advantage will not be generating the most code. It will be repeatedly delivering the greatest useful outcome at the lowest sustainable cost.
6
Closing: The Thesis
Every technological revolution ultimately changes a price. The steam engine changed the price of power. The assembly line — and then China — changed the price of manufactured goods. Global delivery — and India — changed the price of technology services. The cloud changed the price of software distribution. Artificial intelligence now changes the price of software creation — the last price in the stack that never fell.
That change will not be captured by today’s software companies adding coding assistants to existing teams; every competent company will do that, and it will cancel out. It will be captured by institutions redesigned around a new assumption — that software creation is no longer scarce. They will build foundries, not workshops. They will sell utility, not feature volume. They will industrialise quality as aggressively as speed. And they will expand access rather than merely undercut prices — because the largest market is not the customers the incumbents overcharge, but the ones they never reached at all.
The first era of software was about invention — making the impossible possible. The second was about distribution and scale — making it available to every organisation that could pay. The third will be about industrial production and abundance — making it available to everyone else.
Which brings me back to a book I read thirty-five years ago. Cusumano’s Japanese factories were not wrong; they were early. Hitachi, Toshiba, NEC and Fujitsu had the right ambition and the right disciplines — reuse, process, statistical quality — but they were industrialising everything around the craftsman while the craftsman remained the unit of production. The idea then waited three decades for its missing ingredient. I returned to India in 1992 dreaming of building software products, watched two of them fail, and filed the phrase “software factory” away with the other dreams that arrive before their time. It turns out the dream was not dead. It was waiting — for the production function itself to change, and perhaps for a country that had spent those same three decades mastering process, delivery and affordability to be ready to build it. The factory Japan imagined, the foundry can now deliver — and this time, it can be built from India.
China showed the world that industrial production could make physical products affordable. India showed the world that distributed talent could make technology services affordable. AI now makes possible the third affordability revolution — in which high-quality software itself becomes available to every business, not only those able to pay yesterday’s prices.
That is the promise of the software foundry. Not more software. Software for many more people.