Rajesh Jain

The First Intelligent Surface

If the core changes what software costs, where does its intelligence become visible first? The likeliest answer is the oldest digital relationship a merchant owns: the email address.

Today, a smaller merchant uses email as a broadcasting tool, because that is all the affordable tier of the market offers. She chooses a template, writes a subject line, selects an audience and sends. The message is fixed at the moment of sending — and by the time the customer opens it, the world has moved. Stock has changed; the price is different; the customer may already have purchased; the reason for the message may no longer exist. The email does not know. It is a document created earlier, pointing the customer towards a website that knows more. Large brands overcome this with an assembly — unified customer data, segmentation, live product feeds, dynamic content, embedded forms, testing tools and custom engineering: in practice, a marketing-engineering team. Smaller merchants’ messages stay static not for lack of imagination, but because making each message current, interactive and useful has required too many systems and too much specialised labour.

A shared core changes the equation, because the expensive part of a sophisticated message was never the message — it was knowing the business. The core already holds the customer, the catalogue, the orders, the preferences, the permissions and the most recent events. So the message no longer needs to guess at the moment it is sent; it can check what is true at the moment it is opened, and assemble the most useful experience for that customer, then. For one person, the useful thing is a replenishment that is due now. For another, a delivery update. For a third, a compact digest of new arrivals in a category she follows. For a fourth, a single question that will improve every future recommendation. And the interaction can finish inside the message: confirm the reorder, choose the delivery slot, set the preference, leave the review, request the support — without a link, a login and a journey through a website. Each completed action writes what it learned back to the core, which makes the next message better.

The same email address; two different kinds of message.

This turns email from a message into something new: an owned micro-application surface. It begins with a known identity. It costs almost nothing to reach. It can carry content, state, choice and action. It persists and is searchable. And it requires the customer to install nothing. Not every business process belongs inside a message — but many small, high-frequency actions do, and every unnecessary click removed between attention and completion raises the probability that the action happens. A large brand builds such experiences from a patchwork of specialised systems. On one core, they become a standard capability of an affordable product. A small merchant should not need a marketing-engineering team to send a message that is current, interactive and useful.

There is a discipline hidden inside this promise, and it must be said plainly. An intelligent message that never reaches the inbox has no utility. A message that violates permission destroys trust. A message assembled from stale or inconsistent data becomes confidently wrong. The foundry must therefore industrialise delivery, consent, abuse prevention and data quality with the same seriousness as content — speed without trust is not affordability; it is deferred cost. Done properly, the shared core also changes what the system can learn: in the old stack, one application saw the send, another the click, another the order, another the complaint, and no system held the whole story. On one core, context, action and outcome connect — the system learns which interactions help merchants and customers, not merely which buttons collect clicks.

Email is not the whole story; it is the first chapter. The same intelligence — context assembled at the moment of attention, action completed where the attention already exists — will appear on the storefront, in the support conversation, in the messaging thread. But email is where identity, low cost, rich context and immediate action already coincide, which makes it the first place the new production economics becomes visible. And it carries the essay’s larger point: affordability is not only a cheaper price for yesterday’s product. Done right, it is access to tomorrow’s. The small merchant does not receive a stripped-down copy of the old suite. She receives, at last, the kind of software the sophisticated brands kept to themselves.

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.