Published August 8-12, 2026
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.
1
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.
2
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.
3
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.
4
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.
5
Commerce Software for the Many
Follow the architecture forward and the merchant’s relationship with software changes shape. Today, adopting a capability means adopting a company: another vendor, another data copy, another connector, another dashboard, another line of tax. On one core, adopting a capability means something closer to flipping a switch. Installation becomes activation. The new capability does not arrive as a stranger to be introduced to the business over weeks of configuration; it arrives already knowing the customers, the catalogue, the orders, the permissions and the workflows — because the core knew them before the capability existed.
The difference between adopting a company and adopting a capability.
That changes the merchant’s arithmetic in both directions. Adding becomes cheap: minutes to first value, no integration project, no new tax lines. And — this matters just as much — removing becomes possible: because capabilities are thin and the data lives in the core, no capability holds the business hostage, and the switching tax that locked the old stack together loses its grip. The merchant regains the thing the app economy quietly took from her: the ability to change her mind.
Now widen the lens, because every affordability revolution creates two markets, and the second is usually larger. The first market is visible: the switchers, merchants already paying the tax — stacks assembled, bills rising with their own growth, held in place by the fear of leaving. For them the revolution is substitution and consolidation: most of the utility they built from eight applications, on one core, at a fraction of the combined bill, with one version of the truth and the freedom to leave any part of it. That alone justifies everything above. But the second market never appears in any vendor’s win-loss report, because it was never in the market at all. The starters are the majority of the world’s sellers: the storefront is a social profile, the catalogue is a folder of photographs, the customer database is a phone’s contact list, orders arrive through conversations, payments are confirmed in messages, and follow-up depends on memory. The business is digital without being software-operated.
The affordability revolution serves the switchers — and, more importantly, the starters.
Conventional software cannot serve the starters, and the reason is arithmetic, not neglect: the revenue per merchant cannot carry conventional product development, sales, onboarding and support. The foundry changes all four terms at once. When the components already exist, a product can be adapted to a language, a category or a local practice without building a company around it. When onboarding and support are AI-native, a seller can begin without a consultant. When the interface is conversational, the product meets the business where it already operates. And when the price reflects the useful core rather than the accumulated feature set, serious software becomes possible for very small businesses for the first time. They do not need a cheaper version of the stack. They need to never build one — what they receive is not a consolidation but a beginning: the first complete software memory their business has ever had.
Two honesty notes keep the claim disciplined. First, not every category of commerce software becomes cheap: payments, mission-critical order records, fraud systems and regulated infrastructure hold value that sits beyond code — as the first essay put it, that world stays expensive and deserves to; the foundry attacks repeated engineering and fragmented utility, not trust and risk. Second, success carries its own trap: a thriving core will face pressure to add every requested feature, drift upmarket, and slowly rebuild the bloated suite it was born to replace. The discipline is permanent — products thin, core strong, boundaries clear. The foundry does not need to serve every requirement to transform the market. It needs to serve the common jobs extraordinarily well, and make the uncommon ones easier to add.
And the tax, remember, is not a commerce phenomenon. The clinic runs a stack. The school runs a stack. The professional firm, the local manufacturer, the twenty-person logistics company — all of them are unpaid systems integrators for their own software, all paying five taxes for one utility. Commerce is simply where the fragmentation, the repeated foundations and the unmet affordability are all visible at once — where the primitives repeat, the daily utility is concentrated, and millions of sellers wait outside the market entirely. What ends the tax for the merchant ends it, in the same order, for everyone else: foundations once, capabilities on top, the price of the stack falling to the price of an app.
Closing: The End of the Tax
The first era of commerce software gave merchants access to specialist applications. The second assembled those applications into stacks — and quietly billed the assembly to the merchant. The next era must remove the tax the stack created, and for the first time, it can: AI lowers the cost of producing software; a shared core lowers the cost of producing the next software; the double cut concentrates on useful jobs and eliminates repeated foundations; intelligent surfaces make sophisticated capability ordinary; and falling prices bring in the businesses that were never in the market at all.
The companies that do this will not be recognised by the number of applications they announce. They will be recognised by a curve: product two taking less time than product one, product three reusing more than product two, every connector strengthening the portfolio, every price reduction admitting another class of business into software’s reach. The real proof is the economics of repetition. That is the moment a metaphor becomes a production system — and affordable software becomes abundance.
**
The next era of business software will not be won by the vendor with the largest suite, nor by the buyer with the tallest stack. It will be won by a production system that builds the foundations once and manufactures focused capabilities on top — most of the stack’s utility, at a fraction of the stack’s cost, for businesses that could never have assembled today’s stack at all.
The first essay named the revolution: the software foundry. This one names what it abolishes. The app-stack tax is the AdWaste of software — the money every growing business pays for machinery it already bought. Its collection ends when the foundations are built once.
Not more applications for businesses that already have too many. Better software for many more businesses.