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.
