Rajesh Jain

Preamble

A note on the mathematics

I use “second derivative” in two ways in this series, and it is worth separating them up front.

Strictly: the second derivative is the change in the rate of change. If revenue is the level, the monthly addition is the first derivative, and the change in that monthly addition is the second derivative. Where I give numbers, this is what I mean.

As a management lens: the broader discipline of asking whether the engine underneath a headline number is strengthening or weakening — rather than accepting the headline. Some of the metrics below (net revenue retention, inflation) are already rates of change, so watching whether they rise or fall is a second-derivative question even though the arithmetic looks like a simple trend.

The distinction matters because the moment you call every deteriorating trend a “second-derivative signal,” you have said nothing. The test is always: is this a level, or is it already a rate? If it is already a rate, its direction is your second derivative.

**

Watch the change in the change

A simple idea from calculus that warns you about trouble long before your dashboards do — and why the quarter you celebrate may be the quarter the engine turns.

I read an essay recently (“The Second Derivative: Why No One Sees It Coming) arguing that almost nobody sees a turning point coming — not because the warning signs are absent, but because we stare at the wrong number. We obsess over how big a thing is and how fast it’s growing, and we miss the quieter number underneath: whether that growth is itself speeding up or slowing down. By the time growth actually turns negative, the real change happened quarters earlier.

It stuck with me, because it isn’t really about markets or AI. It’s about a number that every operator can track, that costs nothing to compute, and that almost none of us actually watch.

Three numbers, and you already use two of them

Forget the calculus. There are only three numbers here.

THE LEVEL Where you are Revenue this month. Total customers. The number on the scale.

1ST DERIVATIVE How fast you’re moving This month minus last month. Your growth.

2ND DERIVATIVE Speeding up or slowing? This month’s growth minus last month’s. The change in the change.

That third one is the second derivative. Scary name, ordinary idea: is my growth getting bigger or smaller? Think of a car. The level is where the car is on the road. The first derivative is the speedometer — how fast you’re going. The second derivative is your foot: are you pressing the accelerator, or easing off? You can be moving forward and easing off the gas at the same time. The car is still going forward. It’s just about to slow down — and nobody inside feels it yet.

Maya’s record year

Maya runs a direct-to-consumer skincare brand. Business is good, and the proof is on the wall: revenue sets a record almost every month. ₹40 lakh, then 52, 62, 70, 76, 80. Up and to the right. She hires ahead, signs a bigger warehouse, and tells her investors the numbers they want to hear.

Now look at the change each month — the new revenue she added:

+12   +10   +8   +6   +4   +2   … the change in the change:  −2  −2  −2  −2  −2   every single month

Her growth is shrinking even as her revenue breaks records. The second derivative has been negative for half a year. The engine started slowing while every dashboard was still flashing green — because the level, the number everyone celebrates, is the last thing to turn.

Maya watched the top line — a record almost every month. The engine was fading the whole time, visible only in the bottom panel. Same business, two different numbers.

Key point: Record revenue and a dying engine are not a contradiction. They’re the same month, seen with two different numbers.

Here’s the version where Maya wins. She stops celebrating total revenue and starts watching net-new — the revenue she adds each month, not the running total. When net-new slips from +12 to +10 to +8, she doesn’t throw a party for the record; she asks why acquisition is decelerating. She finds it early — a channel saturating, her cost per customer creeping up — and she fixes it while she still has the cash and the runway. Not after the record quarter, when the board is already modelling more of the same.

The mountain that told them, in numbers, for months

Maya is invented. This next one is not, and it is the reason I think this idea deserves more than a dashboard column.

Above the Vajont reservoir in the Italian Alps stands Monte Toc. When engineers filled the reservoir in the early 1960s, the mountainside began to creep — and they measured it, carefully, for years. That the slope was moving was known. It was in every report. The level was never the secret.

What the measurements also showed, for anyone reading the change rather than the amount, was that the slope was moving faster each month. Through 1963 the rate climbed from roughly 0.3 centimetres a day, to 0.5, to 0.8, and then — as the reservoir reached its greatest depth in early September — to about 3.5 centimetres a day. In the final days it passed 20 centimetres a day.

Vajont, 1963: displacement of the Monte Toc slope, in centimetres per day. The mountain had been moving for years. The warning was that each week it moved faster than the week before.

On the night of 9 October 1963 roughly 260 million cubic metres of rock slid into the reservoir in under a minute. The wave it displaced went over the top of the dam and into the valley below. Close to two thousand people died. The dam itself survived — it is still standing. The engineering held. What failed was the reading of a number that had been accelerating in plain sight for months.

Key point: The lesson, stated plainly. The level described the damage already done. The second derivative described the disaster still coming. The first was in every report; only the second could still be acted upon.

I am not suggesting a decelerating SaaS metric is a catastrophe. The point is structural, and it is the same in both cases: the quantity everyone monitors is the one that tells you last. Vajont is what it costs when the accelerating number is measured, filed, and not acted upon. In Part 3 you will meet the opposite case — a mountain where people acted on acceleration before they were certain, and tens of thousands lived.

So what do you actually do about it?

The whole point is to act earlier. Four situations, four moves:

Growing & accelerating Second derivative positive. Pour fuel on it — this is where your next rupee of investment goes.	Growing but slowing Positive growth, negative second derivative. Borrowed time. Everything looks fine; act now, because the fix takes quarters and you only have them if you start before the level turns.
Growth near zero You’re at the top. The second derivative told you this was coming a while ago — this is the confirmation, not the news.	Shrinking It’s in the numbers now. You’re late — reacting, not steering.

The asymmetry is the whole reason to bother. On the way up, the second derivative tells you where to double down. On the way down, it’s your only early warning.

One warning before you go and compute it

There is a catch, and it is serious enough that Part 3 is devoted entirely to it: the second derivative is noisy. Every time you take a difference you amplify the wiggles, so a raw month-to-month reading will “find” turning points that were really a lumpy deal or a slow week. Two rules — smooth first, and never act on a single period — are what separate a useful early-warning system from a smoke alarm that goes off when you make toast. Part 3 covers how.

Once you have the lens, you see it everywhere

Epidemic peaks are called this way: cases still climbing, but the rate of increase falling. Every S-curve turns at its inflection point, exactly where the second derivative flips. Your savings: net worth climbing while your saving rate quietly shrinks. Fitness plateaus, learning curves, a creator’s follower count — same lens, earliest warning, every time. Part 4 takes the idea out of business altogether.

Any S-curve hides its most important moment at the inflection point, where acceleration flips to deceleration. The level still looks great there. The second derivative has already turned.

Key point: Your best quarter may contain your earliest warning. The second derivative is how you hear the bad news while it is still good news — while you can still do something about it.

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.

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.

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.