Rajesh Jain

Published August 14, 2026

This series has moved from the supply side to the demand side to the factory floor. The Software Foundry named the revolution: AI changes the production function of software. The App-Stack Tax named the waste on the buyer’s bill. Inside the Foundry walked the production system that removes it. But one part of the argument has stayed deliberately unfinished: if software is produced differently, what should it cost? A production revolution becomes economically important only when its gains reach the buyer. A faster factory that preserves the old price has improved the producer’s margin; it has not created an affordability revolution. The revolution becomes visible when the invoice changes — and, more importantly, when the changed invoice becomes the number every other producer must explain.

This essay names that number. And it is a number, not a product — which is what makes it the most contagious idea in the series.

The claim of this essay: markets do not change when one producer becomes cheaper. They change when buyers begin treating the cheaper price as normal. Manufacturing learned this as “the China price.” Software is about to learn it as the foundry price — and the most important property of a reference price is that it does its work in negotiations it never attends.

1

The Price Everyone Knows Before the Quote Arrives

The renewal arrives on a Tuesday afternoon, and it is rarely dramatic. The account manager has prepared the explanation before the buyer asks: the customer crossed a contact threshold; three more employees need access; a capability that used to sit inside the package has moved into a premium module; the annual increase is in line with the market. A discount is offered pre-emptively. The final number is close enough to last year’s to feel inevitable and large enough to require a meeting — and the meeting begins too late in the argument. Procurement debates the percentage. The business owner debates which modules to trim. Finance asks about contract length. Everyone negotiates around the quote, because everyone has accepted the invisible number beneath it: what software in this category is *supposed* to cost. The most powerful price in any market is not the amount printed on the invoice. It is the amount the buyer has stopped questioning.

Reference prices form slowly and then govern almost everything. A washing machine made in a high-cost economy is not judged against its own labour and materials; it is judged against the price the global factory system created. A technology project proposed entirely onshore is judged against the offshore rate even when no offshore supplier is in the room. A medicine whose exclusivity has ended is judged against the generic price however eloquently the branded manufacturer explains its history. In the early 2000s, Western manufacturing boardrooms learned the purest version of the pattern: “the China price” was not a quote from any particular factory — it was a number everyone knew before any quote arrived. And notice what it did not require. It did not require the buyer to move production to China; most never did. It did not require the Chinese producer to bid; it usually hadn’t. The number worked at a distance: once a credible alternative existed at a visible price, every incumbent quote had to be *justified* rather than merely *renewed*. Once the reference moves, the incumbent no longer describes its own economics in isolation. It must explain the spread.

The number does its work before any deal is signed.

Business software is the great exception — the largest spending category in the modern company with no reference price at all. Ask a finance director the market rate for a marketing suite, a service desk, or a workflow platform for two hundred people, and there is no number to give: only what the incumbents charge, which is a different thing entirely. The anchor in every software negotiation today is the vendor’s own last invoice; “market rate” means “last year, plus the uplift.” Discounting is theatre performed against a list-price fiction nobody has ever paid. What buyers have instead is a substitute that answers the wrong question — analyst quadrants and review sites that rank vendors by features and vision: comparisons of *what*, never of *what it should cost*. In no other major category does the seller supply both the price and the standard the price is judged against.

One clarification before the mechanism, because software has seen many low prices and very few price revolutions. Open source lowered the licence and moved integration and operation elsewhere. Freemium lowered the entry price and recovered the economics through upgrades. Venture-subsidised challengers entered below cost and raised prices once dependence formed. Those were changes in *commercial strategy* — and buyers learned, correctly, to distrust them. A reference price must be sustainable: it must remain true when the second product ships, the hundredth customer onboards, a connector fails at midnight and the support queue fills on a Monday morning. The foundry price qualifies for one reason only — it is a change in production possibility. The useful product can be made, operated and supported for less because less of it must be invented, repeated and manually carried each time. That is the difference between a cheap bid and a new normal.

2

How Software Escaped Its Cost Curve

To feel why the foundry price will land so hard, trace how software’s price became detached from its production curve — and begin with fairness, because the story is not one of villainy. The cloud bargain was real and overwhelmingly good. Before software-as-a-service, a customer bought licences, ran infrastructure, carried versions, hired specialists and absorbed long deployments; central operation removed most of that burden, and one product could improve continuously for every customer at once. The industry deserved a large share of that dividend. The question is what happened to the rest of it.

What happened was a doctrine — the most successful pricing doctrine in modern business, and it had a name: value pricing. Price the software not on what it costs to make and run, but on what it is worth to the customer. Reasonable on its face; software’s worth is real and often enormous. But notice what the doctrine quietly abolished: any relationship between the number on the invoice and the cost of the thing invoiced. Once price anchors to “value” — unmeasurable, negotiable, asserted by the seller — there is nothing for it to be compared *against*. Value pricing did not merely raise software prices. It removed the standard by which they could ever be questioned. The pricing grammar that followed acquired a peculiar direction: seats, contacts, events, orders, usage bands, editions — almost every sign of the customer’s success became a reason for the invoice to rise. The previous essay watched the merchant’s stack charge her for succeeding; the same mechanism lives inside the individual application, where the bill expands with the customer’s activity while the product performs essentially the same job on the same centrally operated system. The price became less a reflection of the work the software does and more a claim on the growth the customer creates.

The industry’s scoreboards then locked it in. Annual recurring revenue measured the base; net revenue retention measured how reliably the installed base paid more; customer-success organisations were built not only to preserve use but to locate expansion; packaging became a commercial architecture — enough value in the lower edition to enter, enough friction to make the next edition inevitable. None of it was foolish. It was the rational optimisation of a business whose delivery cost had collapsed and whose investors rewarded predictable expansion. The result was the strangest chart in modern economics: the cost of serving a customer falling towards zero while the price of being one rose every year — a gap with a respectable name, gross margin, and a public-market religion, NRR, that made widening it mandatory.

The cost of delivery fell towards zero. The price rose. Nothing forced them back together.

Why was this stable for twenty years? Because the cloud industrialised only half the problem. It industrialised *delivery* — and left *creation* artisanal. Every serious application still required a rare organisation: a team to discover the category, design the product, build identity and permissions, implement workflows, manage connectors, test releases, onboard customers and staff support. The marginal cost of serving another customer fell; the fixed cost of *becoming and remaining a software company* stayed high — and the successful vendor priced to protect the organisation built around that cost. The first essay named the deeper consequence in a different costume: the cost of creating software was the economic patent, and the patent protected more than the product. It protected the price. For a rival number to exist, someone had to build a credible alternative, and nobody could afford to — so no alternative price ever became visible, and the incumbent’s invoice remained the only number in the room.

The foundry attacks the neglected half. Specifications as control surfaces, proven components as tooling, inspection as software, operation AI-native — and the machinery compounding across products, so the second application does not have to buy a second company. When both curves fall — creation and delivery — the old reference price loses its final production defence, and the trillion-dollar repricing of software equities in early 2026 reads correctly at last: not a judgement about chatbots, but the market pricing in the death of a pricing regime — the end of the twenty-year vacuum in which no number ever questioned the invoice. The cloud made software recurring. The foundry makes its old price contestable.

3

What the Foundry Price Is — and How It Spreads

The phrase will be misunderstood unless its boundary is drawn sharply, so draw it from both sides. The foundry price is not the price of code. Code is becoming abundant, but customers do not buy code; they buy a dependable job completed over time — records that stay correct, permissions that hold, changes that do not break yesterday, support when reality finds the edge case. A repository can be generated in an afternoon. A product is a promise that survives contact with the world. So the foundry price *includes* the full cost of that promise: secure identity, tested behaviour, controlled releases, observability, backup and recovery, maintained connectors, documentation that stays aligned, AI-native support with human judgement for consequential exceptions. What it *removes* is everything the third essay showed being manufactured away: duplicated engineering — the same identity layer, workflow engine and connector framework rebuilt for every application; unused complexity — the accumulated features carried by customers who need the common job done well; and avoidable operating labour — the manual onboarding, the support agent asking for information the system already holds. The double Pareto cut, reaching the invoice: one cut removes feature waste, the other removes foundation waste, and the foundry price is what remains when both cuts land.

The definition: the foundry price is the lowest sustainable price for dependable, focused utility produced on reusable machinery. Lowest forces production discipline. Sustainable excludes subsidised theatre. Dependable preserves the trust floor. Focused rejects the bloated suite. Reusable machinery names the economic source. Remove any word and the phrase collapses into ordinary discounting.

Two honesty boundaries keep the definition serious. First, the foundry price is a licence price, not a total-cost guarantee: migration, integration, training and governance remain real and vary by customer; a foundry reduces them — the migration factory exists for exactly this — but it measures and publishes them separately, because a reference price that overclaims dies at its first audit, and the China price never claimed to include shipping. Second, not every category converges to the same ratio. Payments, systems of record, networks with deep liquidity, products built on irreplaceable data, software that underwrites consequential outcomes — that world holds value beyond repeated engineering, can stay expensive, and deserves to. The foundry price attacks the large exposed middle: mature code, understood workflows, accumulated features, and a premium protected mainly by the fear of leaving. In practice: arithmetic lands it at roughly one-tenth to one-fifth of the incumbent licence for the equivalent daily-use utility — with honest margin inside it. Price is the visible output. Production discipline is the warranty.

Now the mechanism — how a number becomes a market force. Three ingredients, and only three. A credible producer: at least one foundry delivering the useful core reliably in a category — not a demo; a running product with customers who stayed. A visible price: published, simple, self-serve — a number a finance director can screenshot into a board pack. A safe exit: migration measured in days and priced in advance, because a reference price backed by an unpriceable switching cost is a bluff, and procurement can smell a bluff. Assemble the three and the propagation begins:

Three ingredients — then the number spreads to negotiations it never attends.

The foundry price does its damage without a single customer switching. It enters renewals as the question the vendor must answer, board packs as the line that makes the current bill look strange, procurement as the benchmark. A market changes not when one producer becomes cheaper — it changes when buyers begin treating the cheaper price as normal.

And it will move faster than its manufacturing ancestor. The China price spread at the speed of trade shows, supplier visits and shipping lanes — a decade to become a boardroom fixture. A software reference price spreads at the speed of a pricing page: the moment one credible foundry publishes its number in one category, every buyer in that category can see it the same afternoon, and every renewal that quarter arrives with the number already in the room. The propagation infrastructure — comparison sites, procurement platforms, analyst notes, one viral screenshot — already exists and is bored. What manufacturing needed a decade to normalise, software can normalise in a renewal cycle or two.

4

The Incumbent’s Six Binds

The obvious question follows: why don’t the incumbents simply match it? They have the engineers, the customers, the data, the brand — and now the same AI models. They will certainly adopt the models: generate more code, automate support, ship simpler interfaces, launch AI features weekly. The mistake is to assume that access to the same technology creates access to the same economics. A new producer asks one question: what price can our production system sustain? The incumbent must ask a harder one: what happens to everything we already are if we admit that price is sustainable? Six binds, and they interlock.

Every response costs the incumbent something it cannot afford.

The valuation bind is the deepest, and a worked example shows why it travels backwards. Suppose the category leader sells at $100 and a foundry offers the common utility at $20. The leader can launch a $20 edition — but every existing customer using only the common utility now has a question, and the revenue risk is not confined to new deals; it propagates through the installed base, which is where the share price lives. Net revenue retention — the promise that existing customers pay more every year — collapses long before any challenger does. The cost bind: the organisation was built to be funded by the old price — enterprise sales, solution consulting, success hierarchies, twenty years of accumulated estate that must be operated precisely because it justifies the tiers; the price cannot fall without the organisation falling with it, which is why incumbents add AI to the product faster than they remove labour from the customer journey. Features are easier to change than organisations. The channel bind: a commissioned sales motion structurally cannot carry a product priced to need no salespeople; the people who would sell the new price are the people it makes redundant, and they know it. The completeness bind: the feature list is the pricing architecture — a focused, honest, cheap edition indicts the suite it sits beside, after years of describing breadth as value. The signal bind: a price cut is a confession that the old price was padding, and it invites the simultaneous renegotiation of the entire book of business — the one event a subscription company cannot survive. And the timing bind closes the cage: respond early and legitimise a challenger nobody had heard of; respond late and the reference price is already normal, at which point matching it merely confirms it.

The binds interlock, which is what makes them a trap rather than a list: escaping one tightens the others. Cut the price and the signal bind detonates; launch the honest edition and the completeness bind indicts the suite; build the separate low-cost brand — the one genuine escape — and the cost and channel binds fight it from inside the building, because the new unit’s success is, by construction, the old organisation’s obituary. None of this makes incumbents helpless: their trust, distribution, data and installed workflows are real, and some will navigate the transition — usually by becoming foundries themselves under separate brands, and usually only after the third bad quarter, because the innovator’s dilemma was never about ignorance; it was about permission. But the asymmetry is now precise. A lower tier is a product decision. A new reference price is a business-model decision. Features invite a roadmap response; price forces an identity response. The incumbent can copy the feature. It cannot easily copy the economics — because its economics are the thing its investors bought.

5

The Renewal Playbook

Everything above becomes practical at one moment: the renewal. So this part changes audience. It is written for the buyer — the founder, the finance director, the operations head with a contract expiring this quarter — and its advice fits in one sentence: negotiate as though the foundry price already exists. In some categories it already does; in the rest, its arrival is a matter of quarters. Seven questions, in order.

Seven questions to ask before signing.

One: which capabilities did we use every week this year? Not which features were enabled or demonstrated — which jobs would cause real pain if removed tomorrow. Pull the usage report; the vendor has it, and reluctance to share it is itself an answer. The answer is usually shorter than the contract — and know the difference between optionality you value and complexity you merely carry: paying for a fire extinguisher is rational; paying for an entire fire brigade inside every room is not. Two: what is the price connected to? If the honest answer is “your headcount and your contacts” rather than “our cost to serve you,” then your growth is being taxed — separate genuine variable cost from a convenient staircase; a contact sitting unused in a database does not cost the vendor what the tier jump charges for it. Three: what does this year’s uplift buy that last year’s did not? An uplift justified by a roadmap you never requested is a habit, not a price. Four: has anyone priced leaving? In most companies the switching cost is a fear, not a figure. Get a migration quote even with no intention of migrating — the moment leaving has a price, staying has a negotiation. Five: what value sits beyond the code? This question protects you from simplistic price aggression: network effects, irreplaceable data, regulatory trust, underwritten outcomes can justify a real premium. The test that separates them from padding: what would remain defensible if migration became safe, common and reversible? Dependence is not the same as value, though it often stands beside it. Six: will the vendor price the used core, alone? The revealing question — a vendor who refuses to quote the fifteen per cent you use is telling you what the other eighty-five per cent is for. Seven, the anchor: if a focused alternative existed at one-tenth the price, what would we pay to stay? Answer it internally, in a number, before the meeting — then negotiate from that number rather than from last year’s invoice. The vendor’s anchor is history. Yours should be the future.

The output of the seven questions is a one-page renewal memo with four numbers on it: the used core, the growth tax, the exit price, and the anchor from question seven. Four numbers, one page — and the meeting is a different meeting, because for the first time both sides arrive with a standard of comparison. Two disciplines keep it honest: this is not advice to buy the cheapest thing — the series’ standard is trusted affordability, and a good incumbent will have answers where a vulnerable one has packaging; and the playbook serves something beyond any one bill. Every buyer who makes the vendor explain the price against the used core is helping construct the reference itself, the way every manufacturer who asked about the China price helped make it a fact. Reference prices are not announced. They are asked into existence, one renewal at a time.

6

When the Price Falls, the Market Expands

Price revolutions are usually described as wars over an existing pool of customers: the entrant undercuts, the incumbent bleeds share, industry revenue shrinks. That is the first-order view, and it is the least interesting thing that happens. The deeper pattern, every time, is expansion. China’s factories did not merely move the same purchases to cheaper suppliers; lower prices put appliances and electronics within reach of hundreds of millions who had never been customers. India’s delivery machine did not only replace onshore projects; it made technology work viable that would otherwise have been deferred forever. Generic medicines did not change the supplier; they changed who could be treated. The market after every reference-price reset was larger than the market before it.

Software is unusually ready for the same effect, because its non-consumption is invisible. The clinic coordinating through spreadsheets, the school running on messaging groups, the manufacturer whose workflow lives in one employee’s memory, the merchant whose customer database is a phone’s contact list — none of them appears in any vendor’s lost-deal report. They did not choose a competitor. They were never candidates at the old price and the old operating burden. The foundry changes all four terms that excluded them at once: creation becomes cheap (the machinery is reused), distribution stays near-zero (the cloud solved it), onboarding and support become AI-native (no consultant required to begin), and narrow categories become viable (no product must fund a complete software company). The addressable market expands downwards in company size and outwards into languages, local practices and specialised jobs.

The market after the reset is larger than the market before it.

The arithmetic that looks alarming is the arithmetic that matters. A product at one-fifth the price needs five times the customers for the same revenue — and conventional analysis stops there, which is why conventional companies will not do this. Foundry analysis continues: can the production system serve ten times the customers at far below one-fifth the total cost, when onboarding, support and operation scale with machinery rather than headcount — and how much of that volume is revenue that did not exist before? Add the portfolio effect from the third essay: a narrow workflow for one profession is too small to justify a standalone company and entirely viable as the seventh product in a foundry, where localisation and category logic sit on already-paid-for tooling. Lower price and larger market build a larger company, not a smaller one — which is the difference between discounting and abundance. Discounting asks how much less a seller will accept for yesterday’s product. Abundance asks what becomes possible when the cost structure itself changes.

One warning closes the argument, because the trap ahead is the industry’s oldest. Successful foundries will feel the pull of the old climb: win with affordability, add features, move upmarket, build the sales and services organisation — and discover, a decade on, that the reference price they disrupted has quietly reassembled itself inside them. The discipline must survive success: products thin, machinery strong, usage transparent, premium reserved for value that truly sits beyond code. The foundry price is not a launch tactic. It is a constitutional constraint. And when the constraint holds, the most important customer is not the enterprise that saves eighty dollars. It is the small business that can finally spend twenty; the specialist whose narrow workflow finally supports a product; the merchant who moves from messages and memory to a dependable system. The affordability dividend is not that today’s buyers pay less. It is that tomorrow’s buyers finally exist.

Closing: When the Revolution Reaches the Invoice

 The series can now be stated in one line: a production revolution (the foundry) removes a category of waste (the app-stack tax) through a machine (specifications, tooling, industrialised quality) — and transmits itself to the entire market through a number. The number is the final piece and the most contagious one: products must be adopted one customer at a time, but a reference price, once credible and visible, changes the behaviour of buyers who never adopt anything. It will not arrive everywhere at once; some categories hold value beyond code and will keep their premium with justification; some challengers will fail by confusing generated code with a dependable product; the reference will form through evidence — products that stay reliable, migrations that become safe, portfolios in which every product makes the next cheaper. Including, as the previous essay promised, evidence of our own, published favourable and unfavourable alike.

But once the evidence accumulates, the market’s question changes permanently. Buyers stop asking whether the new product is suspiciously cheap and start asking why the old one is inexplicably expensive. Vendors will not have to lose a deal to feel it; they will simply, one renewal at a time, have to explain a number they never had to explain before. The quote will no longer begin the negotiation. The reference price will.

**

The old software price was built on scarcity: scarce engineers, repeated foundations, large operating teams. The foundry price is built on abundance — abundant code disciplined by specifications, reusable machinery, industrialised quality, and human judgement concentrated where consequence demands it.

A market changes not when one producer becomes cheaper, but when buyers begin treating the cheaper price as normal.

The software foundry changes how software is made. The foundry price is what happens when the revolution reaches the invoice.

Published August 13, 2026

The Software Foundry named the revolution: AI has changed the production function of software, and a third affordability revolution follows. The App-Stack Tax named what the revolution abolishes: the repeated foundations every business pays for again and again, and the architecture — one core, many products — that ends the tax. Both essays lean on a claim I have so far asserted rather than opened: that there is such a thing as a software production system, as distinct from software development done quickly.

This essay opens the doors and walks the floor. It is written for a particular reader: the builder — the person deciding what to do with the most powerful construction tools ever handed to our industry. Because the awkward truth of this moment is that those tools are available to everyone, and most of what gets built with them will not be a foundry. It will be a faster workshop.

The thesis: AI-generated code is not a software foundry. A foundry is a production system that turns precise intent into dependable software, repeatedly — using specifications as control surfaces, reusable components as tooling, automated quality as inspection, and humans as accountable designers of the system. The model is the ore. The system is the mill.

1

The Workshop and the Foundry

Picture two small teams. Both are talented. Both use the same frontier AI models — the same coding agents, the same context windows, the same per-token prices. Both can produce an impressive working prototype in days. Watch them for six months, and they become different species.

The first team runs an AI workshop. Every product starts from a prompt and a conversation. The agents generate remarkable volumes of code, fast. But each product begins again: a new conversation creates a new repository; the agent chooses a slightly different architecture because the prompt was slightly different; identity is rebuilt, permissions are re-interpreted, logging arrives late, and the tests describe the happy path. The decisions that shaped the product live in chat histories nobody rereads. The team celebrates speed — and speed is real — while debt accumulates at machine pace, because the agents that write code quickly write inconsistency just as quickly. The workshop’s tell is what happens on product two: it starts from a prompt again. Nothing carried over except the people.

The second team runs a foundry. Intent enters as a specification precise enough for machines to execute and other machines to verify. The agents build — but they are instructed to search the existing inventory before creating anything new, they build *from proven components*, and what they generate must pass common gates before any customer sees it. Failures are replayable; operating knowledge flows back into the system; and when product two begins, most of it already exists. The foundry’s tell is the inverse of the workshop’s: the second product is where it gets faster.

The model is identical. The system around it is not.

Here is what makes the fork treacherous: at the demo, the two teams are indistinguishable. Both show a working product; both credit the same models; both are telling the truth. The demo measures the model, and the model is the same. Only repetition measures the system — which means the most important property of a software company is now invisible at exactly the moment everyone is looking. Investors, customers and the teams themselves will spend the next two years confusing impressive first products with production systems, because the evidence that separates them does not exist until product two.

This is the distinction the current discourse keeps missing. The public argument about AI and software is stuck on the model — which model codes best, how many tokens, what percentage of commits. But the model is available to everyone, which means the model is precisely the thing that cannot be the advantage. In the language of the first essay: the generated code is the ore. What separates the two teams is the mill — and the mill has a one-line definition: the difference between a workshop and a foundry is not how much code AI writes; it is how little of the production system must be reinvented for the next product.

A century ago, industrialists learned this same lesson about physical production: the machine tool mattered less than the system of jigs, gauges, tolerances and process discipline built around it. The factories that treated the new machines as faster craftsmen stayed workshops with better tools. The ones that redesigned production itself became something new. Software now stands at the same fork.

Standing at it, a foundry must resist two opposite temptations. The first is to treat every new request as a custom project — that builds an AI services company, fast and unrepeatable. The second is to build the universal platform before shipping a real product — that builds an internal infrastructure programme in search of a customer. The correct sequence is narrower than either: build one real thing, instrument how it was built and operated, then extract only the machinery that proves reusable. A foundry is not designed in advance. It is discovered through disciplined repetition — and the rest of this essay is a tour of the four rooms where the discovery happens: the specification, the tooling, the quality system, and the people.

2

The Specification Becomes the Control Surface

Begin with the most consequential change, and the least visible one. When agents write more of the code, the most important human-authored artefact stops being the code. Code remains the executable artefact. The specification becomes the source of intent — the primary control surface through which humans govern what gets built.

Consider how intent has historically travelled into software: meetings, product documents, tickets, whiteboard photographs, a developer’s interpretation, code review, testing, and a long argument about what was meant. Every hop lost information; the code that shipped was the residue of a negotiation. Slow human execution acted, perversely, as a safety mechanism — there was time for misunderstandings to surface. Agents remove that safety mechanism. The machine is not lazy; it does not pause because the requirement is imprecise. It executes — and a weak specification now generates a large volume of syntactically correct but strategically wrong software, faster than anyone can read it. The faster the machine executes, the more expensive ambiguity becomes.

So the foundry’s first discipline is not prompting. It is executable precision: expressing intent in a form machines can implement and other machines can verify. A serious foundry specification is layered, and each layer answers a different question. Purpose — what job is being completed, and for whom. Behaviour — what the product must do in normal use, stated as observable outcomes. State — what it knows, remembers and changes. Boundaries — what it must never do: the security lines, the data it may not touch, the actions requiring a human. Acceptance — how another machine will know the work is correct: the tests written before the code exists. Operation — how failure will be detected, diagnosed and reversed. The layers are not paperwork; they are the settings on the machine. Change the specification and the production run changes with it.

A worked example makes the difference concrete. “Let managers approve expenses” is a request, not a specification. Which managers? What counts as an expense? What happens when the approver is on leave, the currency is unrecognised, the amount crosses a threshold, the receipt is unreadable, or the employee changes teams mid-claim? Who may override a rejection, and what is written to the audit trail when they do? Which failures block payment, and which merely raise a warning? An agent can generate the screens for this in minutes; the screens were never the hard part. The behavioural truth of the workflow is the product — and every one of those questions is a decision a machine will otherwise make silently, at speed, in whichever direction the ambiguity happened to lean.

Not a pipeline that ends — a loop that learns.

Notice what the figure is and is not. It is not a pipeline with a beginning and an end; it is a loop. The specification drives the build; the build faces inspection; release is controlled; operation produces a trace of what the software did in the world; and the trace flows back — refining the specification, converting failures into permanent tests, teaching the next run what this run learned. In the workshop, the specification (when one exists) helps a developer begin. In the foundry, the specification governs the entire production loop — it is where intent enters, and where learning returns.

This discipline reaches product management too. The traditional product document could remain persuasive while being operationally vague, because a skilled team translated it; the foundry specification cannot hide behind prose. It must separate assumption from fact, normal path from exception, outcome from implementation preference — and state which decisions the machine may make alone, which require verification, and which remain human. It is versioned, diffable, and traceable to the behaviour it produced. All of which creates a craft that does not yet have a name or a curriculum: the writing of specifications that machines execute well. It sits somewhere between product management, systems design and law — the drafting of documents whose every ambiguity will be exploited at machine speed, whose every precision compounds. The people who master it will be to this era what great architects of code were to the last one. And it explains a prediction worth making plainly: in the foundry, the intellectual property that matters will migrate from the codebase — increasingly generated, increasingly commodity — to the specification library: the accumulated, tested, executable statements of what dependable products must do.

3

Components Are the Tooling

In a physical factory, the tooling — the jigs, dies, fixtures and gauges — determines what can be produced repeatedly and to what tolerance. Tooling is expensive to create and priceless once proven, because every subsequent product inherits its precision for free. The software foundry has an exact equivalent, and it is not the AI model. It is the library of proven components: identity and permissions, data models, workflow engines, connector frameworks, interface components, testing harnesses, observability, deployment machinery, billing, support capabilities, security patterns. One clarification before going further, to keep two ideas from blurring: this production tooling is not the shared product core described in *The App-Stack Tax*. One Core, Many Products is an architecture a foundry might *build* — a product decision. The tooling described here is what a foundry *builds with* — the machinery behind every product it will ever make, whatever the architecture.

Here is the accounting change that follows, and it is an unfamiliar one: the code repository is not the balance sheet. Repositories fill up in any AI-equipped team; volume of generated code is nearly free and nearly meaningless. The asset that matters is the reuse ledger: which components exist, which products use them, how reliable each has proven in operation, what each carries in dependencies, what each costs to run — and, the column that justifies the whole ledger, how much production time each one saves when the next product draws on it. A component used once is an expense. A component proven across three products is machinery. Every proven component is stored production time — and the foundry’s net worth is the sum of that column.

The repository is not the balance sheet. This is.

The ledger changes how the agents themselves work. Instead of beginning from a blank context, an agent is required to search the ledger, compare the new requirement against proven patterns, and justify every departure — and it selects on operating evidence, not novelty: which component produced fewer incidents, which connector has known limits, which pattern reduced support questions. The foundry acquires the thing workshops structurally cannot have: institutional memory that survives individual engineers and model upgrades.

The ledger enforces honesty in both directions. It exposes components that were built speculatively and never reused — the foundry’s dead inventory. And it prevents the opposite failure, which has killed more platform efforts than any technology ever has: premature abstraction. The seductive mistake is to build the universal machinery first — the grand internal platform, the framework for every future need — before any product exists to need it. Platforms built in advance of products are speculation wearing an architecture diagram; they generalise from zero examples and are wrong in ways only real products reveal. The foundry’s promotion rule runs the other way: build concretely; reuse deliberately; generalise only after the second real need. A component is extracted from a real product, hardened by a second real use, and only then promoted into the common tooling. The ledger records the promotion — and the temptation it guards against has grown teeth, because agents make frameworks nearly free to generate: a team can now produce an impressive universal layer long before it has discovered the real commonality. A mature ledger therefore records negative knowledge with equal care — the component that is secure but too expensive to operate, the workflow that fits one regulatory context and fails in another, the connector with hidden rate limits. Knowing where reuse is unsafe is as valuable as knowing where it compounds. A foundry’s maturity shows not in the size of its catalogue but in the quality of its boundaries.

Watch what this does to the economics of the portfolio. The first product pays full price: it builds its own tooling as it goes, and most of what it builds is candidate machinery, not proven machinery. The second product is the moment of truth — the essay returns to this at the end. But by the fifth product, something structural has happened: most of a new product is drawn from the ledger, and what remains to build is mostly the product’s one distinctive job. The threshold for viable software falls with every promotion. Products for narrow niches, small categories and local practices — products that could never have carried a full engineering organisation — become economical, because they no longer have to buy their own tooling. The tooling was already paid for, by every product before them. And this is where the durable advantage forms — the answer to the objection that every competitor has the same models. They do. A competitor can reproduce a screen or a workflow in an afternoon. What it cannot reproduce in an afternoon is years of accumulated evidence about which components behave dependably together, under which conditions, at what operating cost. The reuse ledger is not glamorous. Neither is factory tooling. Both are where repetition turns into economics.

4

Quality Must Be Manufactured

Now the objection that every serious reader has been holding since Part 1, and that deserves to be stated at full strength: AI can increase output faster than any organisation increases judgement. Left ungoverned, agents produce brittle code, duplicated logic, insecure dependencies, inconsistent interfaces, and failure modes nobody has mapped — technical debt manufactured at machine speed. The critics who say most AI-built software will be unreliable are not wrong about the workshop. They are describing it accurately. The question is whether the foundry has a structurally different answer — and it does, though it is not the answer people expect.

The expected answer is human review: have experienced engineers read what the machines wrote. At foundry volumes this is arithmetic nonsense — humans reading machine-speed output either become the bottleneck that erases the production advantage, or become a rubber stamp that erases the safety. The foundry’s answer is the one manufacturing found a century ago, when production outran craftsman inspection: industrialise the inspection itself. Machine tools did not make quality control obsolete; they made *statistical* quality control necessary — specifications with tolerances, gauges at every station, sampling, traceability, the discipline Cusumano documented the Japanese software factories borrowing from their own assembly lines. The foundry completes what those factories started, with the ingredient they lacked: generated code makes inspection more important, not less — but inspection must itself become software.

Six gates between generated code and the customer — and a loop that makes each failure permanent knowledge.

The gates come in layers, each catching what the previous cannot. Static controls first: schemas, types, dependency policies and security rules that reject bad structure before anything runs — the cheapest gate, so it runs on everything. Behavioural tests next: unit, integration, contract and end-to-end — and note that in a foundry these are largely written *before* the code, because they are the specification’s acceptance layer made executable. Adversarial tests third: unexpected inputs, permission probing, corrupted data, misuse and attack paths — machines are tireless red-teamers of other machines’ work. Then the gates that operate in the world: controlled release (flags, staged rollout, shadow operation, instant rollback — the assumption that something will eventually be wrong, built into the delivery mechanism); operational inspection (observability, anomaly and drift detection, cost monitoring — the software watched as closely as it was tested); and finally failure replay, the gate that makes the whole system compound: every significant incident captured with its state, inputs and component versions, reproduced, understood, and converted into a permanent test, so the same failure can never ship twice. In a workshop, an incident is repaired. In a foundry, it becomes production machinery.

Consequence, not convenience, sets the level of autonomy at each gate. A cosmetic change moves through the automated path end to end. A permission change, a payment decision, a deletion of customer data — anything whose failure cannot be cheaply reversed — carries heavier gates and a named human approver. The foundry classifies every change by what it could cost, and grants the machines exactly as much independence as the evidence supports: autonomy is earned through evidence, not declared through ambition. And the same production system extends past release into operation, because at radically lower prices the old support model — large success teams, manual diagnostics, repeated explanations — cannot survive. The product must explain itself: structured logs, replayable failures, documentation that updates with the specification, diagnostics that identify likely causes. Human experts remain, concentrated on the novel and the consequential. AI-native operation is part of the production system, not an economy measure bolted on to protect margins.

Two properties make this a production system rather than a checklist. First, the gates are common: every product passes the same inspection, which is what makes quality a property of the foundry rather than a property of whichever team was careful. Second, the loop learns: each replayed failure hardens the gates for every product at once — one product’s incident becomes the whole portfolio’s immunity. This is the honest answer to the slop objection, and it is also the honest standard from the first essay, restated for engineers: trusted affordability means the price fell because waste was removed — duplicated tooling, unused features, manual inspection — not because responsibility was removed. The question a foundry must answer is never whether every line was manually perfect. It is whether the production system detects variation before the customer pays for it.

5

The Craftsman Is Elevated

End where the anxiety is: the people. The shallow version of this era’s story says agents write the code, so fewer engineers are needed — a subtraction story. The foundry’s story is a relocation: the human moves to the level where judgement has more leverage. Nothing in the four rooms above is unmanned. Someone chose which problem was worth a product. Someone wrote the specification’s boundaries — decided what the software must never do. Someone set the architecture, decided what gets promoted to common tooling, judged the exception the gates flagged at 2 a.m., and accepted responsibility for the consequential release. Someone maintained taste — the difficult ability to distinguish a feature that can be generated from a product that should exist. The machines run the loop. Humans design and govern the system — and governing a production system is a larger act of engineering than operating inside one.

This produces a role that existing job titles describe badly. The foundry builder combines product judgement (which job, which user, what sufficiency means) with systems design, specification craft, agent orchestration, quality engineering, and — unusually for an engineering role — economic thinking: what a component costs to run, what reuse is worth, when a product’s margin makes it real. The temperament matters as much as the skills, and it is specific: low ego about who wrote the code, high ownership of the outcome. Comfort moving between product and engineering without treating the border as a wall. The instinct for reuse without the vice of premature abstraction. An obsession with measurement — because in a foundry, the scoreboard is real and public. A willingness to let machines do everything routine, joined to an absolute refusal to delegate judgement. Some of the best people for this work will come from conventional engineering; some will not have written production code for years; a few will be product people who discovered they can now build. What they share is the ability to be accountable for a system rather than proud of a component. The organisation reshapes itself around them: the traditional decomposition — product, design, frontend, backend, QA, infrastructure, support, and the coordination overhead between them — does not vanish, but most of it moves *into the production system*, leaving a small number of people concentrated on end-to-end outcomes. The culture that makes this safe is unusually explicit about responsibility: every product has named human owners for its purpose, its safety boundaries and its economics; high-consequence changes have clear approval; exceptions are reviewed as opportunities to strengthen the system, not as embarrassments. The team is small enough that nobody can hide behind a function, and disciplined enough that nobody must remember everything personally.

The craftsman is not eliminated. The craftsman is promoted — to designer of the system.

And here the essay must be honest about its own boldest claim. Everything above implies that a small team governing a strong production system can outperform a much larger organisation coordinating specialised workshops — that five people with a foundry beat fifty with better tools. I believe it. I cannot yet prove it, and neither can anyone else, because the claim is not a philosophy; it is a wager with numerical terms. The wager: that the small team wins on elapsed build time, on quality reaching the customer, on support load per product, and on the economics of each successive product — measured, not assumed from headcount. A small team can fail faster too; if five people produce fragile products that require an invisible army of rescuers, nothing has been transformed. Headcount reduction is not proof. Reliable utility per unit of human judgement is proof. And it is worth stating what the wager is not: it is not a claim that engineers have become unnecessary, nor that judgement has become cheap. The foundry team is small because its leverage is high — every person governs machinery that multiplies them — and the moment the numbers say otherwise, the honest response is to change the system, not the scoreboard. Every era’s production revolution attracted true believers before it produced evidence; the believers who mattered were the ones who instrumented the factory and published the numbers. That is the temperament this work rewards, stated one final way: the foundry does not ask anyone to believe. It asks them to measure.

The foundry also changes what mastery means, and this may be the deepest cultural shift of all. In the workshop, mastery is visible in the artefact — elegant code, a clever algorithm, a difficult integration pulled off. In the foundry, mastery is increasingly visible in what no longer requires heroics: the dependency standardised, the class of defect caught automatically, the release that rolled back before a customer noticed, the support problem that diagnosed itself, the new product that inherited weeks of work without inheriting yesterday’s mistakes. The highest craft is embodied in the system — which is why the question a foundry asks of every finished product is not “was it impressive?” but “what did it teach the system never to build from scratch again?”

Closing: Product Two

Which is why this essay must end by disqualifying its own most likely misreading. The first product to come out of any foundry — mine or anyone’s — will prove almost nothing about this essay. A talented team with powerful agents can build one impressive application; the workshop can do that too, and 2026 will be full of impressive first applications. The first product proves demand. The test begins with repetition. Does the second product draw on the ledger instead of starting from a prompt? Does it inherit the gates, connect to the existing machinery, and reach dependable operation in a fraction of the time? Does the third become easier still?

Those questions have numerical answers: elapsed build time, percentage of components reused, defects escaping to customers, support load per product, connector effort, operating cost. When those numbers exist for our own foundry, I will publish them — the favourable ones and the unfavourable ones, because public pre-commitment is what stops a metaphor from grading its own homework. If the curves do not move — if the second product turns out to be another act of concentrated craftsmanship — the honest conclusion will be that a new software company was built, not a new production system. A production system deserves to be measured by production. Until then, everything in this essay is exactly what it claims to be: a description of the machine, offered before the machine has run long enough to be judged. The first essay in this series named the revolution. The second named the waste it removes. This one has shown the machine that removes it. The next will show the dials.

Illustrative — the shape is the claim; the numbers are the promised sequel.

**

AI-generated code is not a software foundry. A foundry is specifications as control surfaces, components as tooling, inspection as software, and humans as accountable designers of the system — judged by one measurement: whether every product makes the next one cheaper, faster and safer to produce.

The workshop celebrates what it built. The foundry measures what it will never need to build again.

Not code without craftsmen. Craft embodied in a system — and multiplied.

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.

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.