Rajesh Jain

One Core, Many Products

The Software Foundry introduced the double Pareto cut: identify the 10–20% of features that carry 80–90% of a customer’s utility, and deliver that utility at 10–20% of the price. That cut operates inside an application. Most smaller merchants use a narrow set of jobs repeatedly — capture an identity, communicate, recover an unfinished journey, request a review, recognise loyalty, recommend a product, understand what happened — while paying for years of accumulated controls and edge cases built for someone else. The cut removes the accumulation and keeps the jobs. One discipline note belongs here, because it separates focus from corner-cutting: a product that performs eighty per cent of a job badly delivers none of the utility. Pareto software is focus, not neglect — fewer capabilities, each coherent, secure and dependable.

The app-stack tax reveals a second cut, and it is the more powerful of the two. It operates across the stack: build the common foundations once — identity, customer, catalogue, orders, events, consent, workflows, content, analytics, connectors — and let every application become only the job it exists to perform. The first cut removes unused features. The second removes duplicated foundations. The first makes one product affordable. The second makes the whole stack affordable, because the four-fifths of every application that was the same machinery is no longer built, operated and billed eight times. It is built once.

The architecture the collapsed cost of software makes possible: one core, many thin products.

Call this architecture One Core, Many Products. To the merchant, each capability still appears modular — install campaigns, add reviews, switch on loyalty — each a small decision, each independently useful. Underneath, they share one memory of the business: one customer record, one catalogue, one order history, one consent ledger, one workflow engine, one set of reports that finally agree with each other. This is not the suite reborn: no capability drags the others in, and no product carries twenty years of accumulated features. And it is not the stack: nothing is duplicated, and nothing needs a connector to talk to its own siblings. When each application owns its own foundations, modularity means repeated infrastructure. When applications share them, modularity means genuine choice — the merchant adds a capability, not another company to manage.

Three economic gains follow, and they are worth naming because they are different sizes of claim. Substitution: focused products replace expensive, overbuilt applications — the familiar promise, at an unfamiliar price. Consolidation: the shared core removes the repeated software and integration cost — the stack’s utility at roughly the price of one app. And innovation, the layer that stops this being merely discount software: once the core exists, the threshold for useful software falls everywhere. Consider a specialised replenishment product for one narrow category. In the old model, the company building it would need identity, catalogue integration, events, workflows, billing, analytics, security and support before writing a line of category logic — and the niche might be too small to carry that company. On a shared core, the product is mostly a domain model, a decision flow and an interface. The core is a market-expansion machine: it makes smaller categories, local practices and narrow workflows economically viable for the first time.

The same consolidation transforms support. A fragmented stack generates fragmented help: the merchant describes one business problem to five vendors, each responsible for a component and none for the outcome. A shared core gives an AI support system the complete picture — customer state, configuration, workflow history, connector status, recent failures — so most routine problems can be diagnosed across the system rather than bounced between its parts. And quality must be industrialised with the same seriousness as speed, exactly as the first essay argued: common security controls, automated tests, observability, failure replay and rollback are part of the production system, because a foundry that manufactures faster while shipping unreliable products has merely moved the cost from development to the customer. Trusted affordability is the standard: a lower price because waste has been removed, not because responsibility has been removed.

One honesty note, carried over from the first essay: this architecture has a test, and it is not the first product. Anyone can build one application with concentrated effort; the first product proves demand, nothing more. The foundry is proven by the second product — built mostly from the core, in a fraction of the time, adopted by the merchant in minutes because the core already knew her business. If the second product needs a second identity layer, a second connector framework and a second long development cycle, nothing has been industrialised; two apps have been built, and the tax survives. That single measurement — does every product make the next one cheaper? — separates the companies that end the app-stack tax from the companies that merely join the stack.

Why the Stack Became the Product

 Nobody designed the app-stack tax. It emerged — from four forces that were each, on their own terms, triumphs.

The first was cloud distribution: once software could be delivered as a service, a company no longer needed a suite to reach customers; it could build one sharp tool and sell it to the world tomorrow. The second was the marketplace: app stores made discovery nearly frictionless — thousands of applications, each a click away, each promising to solve exactly one problem. The third was venture economics, which rewarded precisely this shape of company: the focused point solution that could grow fast in a narrow category was fundable; the patient generalist was not. The fourth was the API — the promise that all these sharp tools would compose into a coherent whole, and that the merchant could assemble best-of-breed pieces into something better than any suite. Each force was real progress. The app economy gave small businesses access to capabilities that once required custom development. But success created a new failure, and it has a precise economic signature: the app economy modularised supply and fragmented demand. Vendors received clean product boundaries; merchants inherited the integration problem. The application became simpler for the maker, and the stack became more complicated for the buyer.

The fragmentation is especially perverse in commerce, because commerce is a chain of linked events. A visitor becomes known. A known person becomes a buyer. A buyer receives a product, asks a question, leaves a review, earns a reward, returns for a refill, recommends the store — or quietly disappears. The same identity, catalogue, order, consent and interaction data flows through the entire chain. Yet the industry divided the chain into separate applications, each optimising one moment and charging for its own partial memory. The buyer’s business is one continuous relationship; the buyer’s software is a row of toll booths along it.

Underneath the tolls sits the duplication. Consider what any serious commerce application must contain before it does anything distinctive: identity and accounts; a copy of the customer, usually the catalogue and the orders; an events system; consent management; a workflow engine; notifications; reporting; billing; support. Engineers inside these companies know the uncomfortable ratio: the distinctive job is perhaps a fifth of the application; the other four-fifths is the same machinery, rebuilt again. The reviews app rebuilt it. The loyalty app rebuilt it. The forms app rebuilt it. Each vendor had a rational reason — it could not rely on the others — and the merchant paid for the machinery every time: eight subscriptions, one job each, the same foundations resold eight times over.

The obvious rejoinder is the suite: if fragmentation is the problem, buy everything from one vendor. But the suite is the other jaw of the same trap. As The Software Foundry argued, the suite pursues completeness — every feature any customer ever requested — and completeness is precisely how software became bloated and expensive in the first place. Consolidating the invoice while preserving the bloat does not remove the tax; it moves the complexity from between applications to inside one application, and adds a new exposure: total dependence on a single vendor’s pricing power. The merchant is thus offered two bad architectures — a tall stack of thin apps that duplicates the foundations, or a single fat suite that duplicates the features — and the entire app economy has been an oscillation between them, bundling and unbundling and rebundling, because until now there was no third option. The foundations were expensive to build, so either everyone built them, or one vendor built everything.

What changed is the subject of the first essay: the cost of building software has collapsed. And that collapse makes a third architecture possible for the first time — one that keeps the focus of the thin app and the coherence of the suite, without the duplication of either.

In The Software Foundry, I argued that the price of creating software is collapsing — that AI has changed the production function of the industry, and that a third affordability revolution is coming, after China’s in products and India’s in services. That was the supply-side argument: how software gets made, and why it is about to get made differently.

This essay begins from the other side of the transaction. What exactly has become unaffordable for the buyer? The answer is not the price of any individual application. It is the cost of assembling a business from applications that repeatedly rebuild the same foundations — and then ask the customer to operate the connections between them. The bill that follows is a composite, but every growing business will recognise it. The tax has been hiding in plain sight, one reasonable subscription at a time.

The claim of this essay: businesses are not overpaying because individual applications are expensive. They are overpaying because every application rebuilds, reconnects and resells the same foundations. The unit of software has been defined incorrectly — the buyer does not experience isolated applications; the buyer experiences one business. The coming revolution will not merely cut the price of apps. It will end the tax of the stack.

**

The Merchant’s Software Invoice

At 9:12 on the first Monday of the month, a merchant opens the business bank statement. She could sell skincare, or spice blends, or handmade furniture; it does not matter, because she is every merchant. The store had a good month — orders up, repeat purchases improving, the small team pleased. Then the software charges begin to scroll past.

She remembers buying every one of them. Customers needed to hear from her, so she added an engagement and email application. Shoppers wanted proof: reviews. Repeat buyers deserved recognition: loyalty. Visitors were leaving without a trace: pop-ups and signup forms. Questions were piling up: a helpdesk. Her best product is bought monthly: a subscriptions manager. The store should suggest the right next item: recommendations. And she needed to know what any of it was achieving: analytics. Eight decisions, spread over three years, each made on the day a real problem appeared. Every single one of them was rational. No merchant wakes up one morning and decides to assemble eight applications. The stack is built one sensible purchase at a time — and becomes unreasonable only when seen as a whole.

Every line is defensible. The total is not.

Six hundred and ninety-eight dollars a month. For many growing stores it is the second-largest fixed cost after rent — and unlike rent, it rises on its own, because most of these applications price by contacts or orders. Every new subscriber she wins makes the engagement app more expensive; every new order makes three other apps more expensive. There is a quiet perversity here that deserves its own sentence: the stack charges her for succeeding. The pricing is not connected to the utility she receives; it is connected to the growth she creates. And the monthly format disguises the scale — software arrives in small recurring amounts, so the stack never triggers the scrutiny of a new hire or a large campaign, even as a dozen modest subscriptions become a substantial annual commitment.

But the subscriptions are only the visible tax. Look behind the invoice and four more taxes appear.

The subscription tax is the one she can see: another bill for every job, accumulating faster than revenue. The data tax is quieter: eight applications means eight partial models of her business — one knows what the customer bought, another what she clicked, a third the points she earned, a fourth the support conversation. Each product calls its fragment a customer profile; together they are pieces of one relationship, and the merchant pays each vendor to store, interpret and act on information she already owns — then pays again when the copies drift apart. A customer unsubscribes in one system and stays active in another. A product is out of stock in the storefront and still recommended in a campaign. A refund lands in the order system but never reaches the loyalty balance. The stack does not merely hold data; it manufactures disagreement.

The connector tax is the glue. APIs promised modularity, and delivered it — while quietly shifting the responsibility. A connector is not a pipe installed once; it is a small living product that must survive change at both ends — authentication, schemas, field mappings, limits, retries, error states — and when either end updates, a workflow fails silently, discovered only after a customer has received the wrong message. The operator tax is her own attention: eight dashboards, eight vocabularies — one system’s *segment* is another’s *audience* is another’s *list*; one reports attributed revenue, another assisted, another last-click — and someone must learn which number to trust. That someone is her. Large companies hire teams to operate software; the small business turns the founder into the integration department. And the switching tax is the trap at the end: the more connected the stack becomes, the harder any piece is to remove — the fear of losing history, templates, workflows and integrations exceeds the resentment of the bill. The stack turns inconvenience into captivity.

The subscription is the visible tax. The other four compound quietly beneath it.

Here is the paradox in one sentence: software was supposed to simplify the business, and the software stack became another business the merchant must operate. No single line on her invoice is outrageous. The stack is. And the stack — not any application on it — is the true subject of the affordability revolution.

The same lens on everything

Once you can feel the second derivative, you can’t unsee it — in the economy, in the stock market, and in your own life.

The reason this idea is worth internalising isn’t that it improves one dashboard. It’s that it’s a way of reading any number that moves — and once you have it, you notice that most people, companies and markets are obsessed with the level and blind to the momentum underneath. That blindness is an opportunity.

Inflation is a first derivative. The news is in the second.

The clearest public example runs on the news every month, and it is worth getting the arithmetic exactly right, because most commentary does not.

The price level is the level. Inflation is the first derivative — the rate at which that level is rising. And the argument central banks have with themselves is almost entirely about the second derivative: is inflation itself rising or falling? “Prices are still going up, but more slowly than last quarter” is a second-derivative sentence, and whole interest-rate decisions turn on it. Note that prices never had to fall for the story to change — the level can keep climbing while the news gets better every month.

Prices rise every quarter (top). Yet the story that moves markets is the bottom panel — the rate of increase peaking and falling. Same data as any headline; the second panel is the one that matters.

The stock market is a second-derivative machine

Here’s a puzzle that makes sense only through this lens: a company posts record profit, beats every estimate — and the stock falls hard. How? Because a share price reflects expectations, and expectations are built on the derivative of growth, not its level. If a company was growing 40% and is now growing 30%, that’s still spectacular — and still a deceleration. The market had priced the acceleration continuing. When the second derivative turned, the price re-rated, record earnings and all.

Key point: “Priced for perfection” is just a market saying that the second derivative is already assumed to be positive. Any hint that growth is decelerating — even from a great level — is enough to break the stock. What was being bought was never the level; it was the momentum.

Your own life has a second derivative too

The same drift that hides inside a record quarter hides inside a good year. The level looks fine; the momentum has quietly turned. A simple personal dashboard, read for acceleration rather than level, catches it early:

A skill you’re building Level high · improving faster each month COMPOUNDING — invest more	Savings Net worth up · saving rate quietly falling LIFESTYLE CREEP — act now
Fitness Still improving · rate of gain fading PLATEAU FORMING — change method	A close relationship Fine on the surface · time together thinning WATCH — the drift precedes the rift

None of these is a crisis yet. That’s exactly the point. Read only the level and each looks okay; read the second derivative and you see which ones have already turned — while a small correction is still enough. And the same caution from Part 3 applies with more force here, not less: one bad week is not a trend, and a life is a noisier series than a P&L.

Why this is an edge

Most people, teams and institutions are level-obsessed. They celebrate records, anchor on totals, and feel the turn only when it becomes undeniable — the one moment it’s too late to respond gracefully. Training yourself to feel the second derivative early is a genuine, durable edge, in business and investing and life, precisely because so few others bother.

Key point: It was never about calculus. It’s about noticing that something has changed while the change is still small enough to answer with grace instead of panic.

The whole series in one line

Levels tell you where you are. Flows tell you what is happening. Changes in flows tell you what may happen next.

So watch the level, of course, and the growth. But add the one column almost nobody keeps — the change in the change — smooth it, confirm it over three periods, and read it on the things you care about. Then ask the harder question Nokia missed: whether the curve you are winning on is still the curve that matters.

Never accept a record level without asking what is happening to the engine producing the next increment.

 **

Try it on your own numbers

I built a small interactive tracker to go with this series. Paste in a metric — monthly revenue, MRR, customers, anything — and it computes the net-new, the change in the net-new, and the growth rate, then tells you which of the four states each line is in. It runs entirely in your browser; nothing is uploaded anywhere. Two worked examples, one SaaS and one D2C, are loaded to start.

How not to fool yourself

The second derivative is a smoke alarm that also goes off when you make toast. Here’s how to keep it useful instead of maddening.

Here is the honest thing most write-ups leave out, and it can turn a good instinct into a bad habit: the second derivative is noisy. Every time you take a difference, you amplify the wiggles. Track the change in the change raw, month to month, and you will “detect” a dozen turning points a year, almost all of them fake — a lumpy deal, a slow week, a holiday. React to those and you’re worse off than someone who never looked.

The two ways to get it wrong

Crying wolf. You watch the raw number, it dips, you act. You kill a channel on one bad month, reverse next month, and whipsaw your team into strategy-of-the-week. The signal was noise; your reaction was real, and expensive.

Sleeping through it. Over-correct for noise — smooth everything into oblivion, wait for certainty — and you smooth away the real turn too. By the time you’re sure, the level has already rolled and you’ve given back the entire early-warning advantage.

The whole craft is holding the middle: sensitive enough to catch the real regime change a quarter or two early, disciplined enough to ignore the rest.

Same data, two readings. The grey raw line flips sign almost every month — react to it and you’ll thrash. The green three-month average tells the one true story: a steady decline. Smooth before you interpret.

Dev thrashes; Priya waits

Two founders, same noisy dashboard. Dev reacts to every twitch — cuts spend on a soft month, reinstates it on a good one, reorganises around each wobble. His team stops trusting the strategy because it changes with the weather. Priya has one rule: nothing moves on a single period. She waits for three in a row pointing the same way. She misses the noise entirely — and when the real deceleration comes, she catches it on the third confirmed month and acts once, calmly, while she still has runway. Same data, opposite outcomes. The difference was a rule, not a metric.

Pinatubo, 1991: acting before you are certain

Part 1 ended at Vajont, where an accelerating measurement was recorded and not acted upon. Here is the same physics with the opposite ending.

In April 1991, Mount Pinatubo in the Philippines — quiet for centuries, with no living memory of an eruption — began producing steam explosions. Scientists from the Philippine Institute of Volcanology and Seismology and the US Geological Survey put in a monitoring network and watched several indicators strengthen together: earthquake swarms, sulphur dioxide emissions, ground deformation. No single number was conclusive. Each was noisy. Together they were accelerating.

They issued warnings and pushed for evacuation before they were sure — and they were explicit, afterwards, about the bind they were in: an overstated warning would mean a hugely disruptive evacuation and the loss of the credibility they would need if a real emergency followed. That is precisely the crying-wolf problem, with lives on the scale instead of a marketing budget.

More than 60,000 people left before the climactic eruption on 15 June 1991 — the largest eruption anywhere in over half a century. The USGS estimates the forecast and evacuation saved at least 5,000 lives and around $250 million in property; other estimates run considerably higher. Several hundred people still died.

Same physics	What was seen	What was done	Outcome
Vajont, 1963	Slope movement accelerating for months	Measured, recorded, filed	~2,000 dead
Pinatubo, 1991	Several weak signals strengthening together	Acted on before certainty	60,000+ evacuated

Two things carry over from Pinatubo into any operating dashboard. The first: the second derivative rarely arrives as one clean number. It usually shows up as several weak signals starting to strengthen at once — pipeline softening a little, expansion slowing a little, a cohort activating a little later. Any one of them is dismissible. The pattern is not.

The second: early warnings are valuable precisely because they arrive before certainty. If you wait until the evidence is unambiguous, you have waited until the level turned, which is the one point at which the information is worth nothing. Acting under uncertainty is not a flaw in the method. It is the method.

Five rules that keep it honest

1. Smooth first. Use a rolling three-month average before you ever look at the change in the change. Look at trend, not last Tuesday.
2. Confirm before you act. One period is noise. Three consecutive periods in the same direction is usually a signal. Three is a rule of thumb, not a law — calibrate it to how volatile your own metric normally is.
3. Kill seasonality. Compare like-with-like — this Q1 versus last Q1 — or use a year-over-year view. Seasonality is the number-one source of fake turning points.
4. Know your normal wiggle. Every metric has a natural range of noise. Learn it. A move inside that range isn’t a signal, however much it looks like one.
5. Use a bigger denominator. Monthly data on a small business is mostly noise. Quarterly is calmer. Don’t differentiate a number that’s too small to be stable.

The seasonality trap

The most common fake second derivative is a season. If every fourth quarter is soft and every second quarter strong, the raw change flips sign on a schedule — and a naïve reader “discovers” a crisis every single Q1. It isn’t a turn; it’s a calendar.

This business is growing steadily. But the seasonal sawtooth makes the raw change flip every Q1. Compare each quarter to the same quarter last year and the fake alarms vanish.

Key point: Confirmation costs you lead time. Waiting for three periods means you act a quarter later than the theoretical earliest signal. That trade is almost always worth it: a false alarm that makes you yank a working channel is far more expensive than a true signal caught one quarter later. You’re buying reliability with a little speed — and reliability is what makes anyone believe the alarm next time. The Pinatubo scientists were making exactly this trade, with far more at stake.

The last rule: it’s an alarm, not a diagnosis

Even a confirmed second-derivative signal doesn’t tell you why. It raises a question — “our adds have shrunk three months running, why?” — and points you at where to look. Don’t act on the number; investigate the cause, then act on that. The second derivative’s job is to make you ask the right question a quarter before you’d otherwise have thought to.

One exception is worth naming, and Vajont is why. An alarm that is itself accelerating should not be averaged away. Smoothing is a tool for separating signal from noise in the ordinary range. When the rate of change is itself climbing steeply — 0.3, then 0.8, then 3.5, then 20 — that is no longer noise to be filtered. That is the thing you were watching for.