Rajesh Jain

Published September 14, 2026

Ten essays on what happens when software becomes cheap to make — and on everything that did not become cheap with it

This series began with a book from 1991 and ended with a set of pre-commitments. Between the two it moved from an argument about production, to an argument about what software becomes, to an argument about the shape of the company that follows.

This essay is a map for anyone arriving now, and a reference for anyone who read them out of order. Each brief states what its essay settles, so that a reader can take the four or five that matter to them and leave the rest.

The argument in one line: AI collapsed the cost of producing software and left untouched everything that makes software dependable — so the opportunity is not cheaper code, but a company built around the half that did not change.

The ten essays, and the three movements they fall into.

I · The Revolution

The first four essays make an economic argument and never leave it. Production, waste, machinery, price.

1

The Software Foundry: The Third Affordability Revolution

Opens with Michael Cusumano’s Japan’s Software Factories, published in 1991, which documented Hitachi, Toshiba, NEC and Fujitsu attempting the move from craft to factory modes of software production. They were early by three decades, and the essay asks what changed. Software remained the last artisanal industry — scaled by adding people rather than by industrialising method — and AI is the first thing to alter that.

It introduces the double Pareto cut: most software is over-built for most buyers, and most products rebuild foundations that already exist. It argues why incumbents cannot follow a price they could otherwise match. And it names the prize as an affordability dividend rather than a margin one — the point is not that today’s buyer pays less, but that tomorrow’s buyer finally exists.

2

The App-Stack Tax

The same argument from the buyer’s side. The problem is not that any single application is expensive; it is that a growing business assembles itself from applications that each rebuild the same identity, data, permissions and workflow — then hands the customer the job of connecting them. The tax was never charged. It accumulated, one reasonable subscription at a time.

It rejects the obvious remedy along with the disease: the monolithic suite is not the answer to fragmentation. The architecture it names instead is One Core, Many Products — shared foundations underneath focused products, with Pareto software understood as focus rather than neglect.

3

Inside the Foundry: The Machine That Makes the Machines

Written for the builder, and it begins with a warning: the tools are available to everyone, and most of what gets built with them will not be a foundry but a faster workshop. AI-generated code is not a production system.

It walks the floor. Specifications become the control surfaces that govern the production loop. Components become the tooling. Quality is manufactured through controls built into production rather than inspected afterwards. And the craftsman is elevated rather than removed — the judgement moves upstream to architecture, domain truth and exceptions. It closes on the test the whole series is later judged by: the workshop celebrates what it built; the foundry measures what it can build next.

4

The Foundry Price

The essay that turns a production argument into a market one. A faster factory that keeps the old price has improved a margin, not started a revolution; the revolution becomes visible when the invoice changes, and contagious when the changed invoice becomes the number every other vendor must explain.

It defines the foundry price as the lowest sustainable price for dependable software produced this way — not a subsidised discount — and shows how such a number spreads without a single customer switching, by appearing in renewal conversations the producer never attends. It sets out the incumbent’s six binds, of which the valuation bind is the deepest, and ends with a renewal playbook of questions a buyer can ask before signing.

II · The World It Creates

Two essays that step outside any one company and ask what has changed about software itself. They are the intellectual centre of the series, and they can be read without the other eight.

5

Software After Code

The flagship. Three shifts: handwritten to generated, as specifications replace code as the source of truth; maintained to regenerated, so software need not age the way it always has; and operated to authorised, as software stops waiting to be used and begins acting within delegated boundaries.

It supplies the operating discipline of the era — humans edit the specification, machines regenerate the implementation — and its honesty condition: the new technical debt is specification debt. A poor specification regenerates bad software faster and across more products than any human team could. It corrects the popular claim about agentic software, which is not deterministic giving way to agentic but agentic control over deterministic execution, permanently, for the sake of both margin and the audit trail. And it raises the objection the next essay exists to answer.

6

The Expensive Last 10%

If producing software has become cheap for vendors, it has become cheap for customers too. Many will build what they used to buy, and some should. The essay grants that fully, then makes the distinction the whole series turns on: self-building does not remove the software producer. It relocates the producer inside the customer — along with the specification, the connectors, the incidents, the regulation, the continuity and the answerability.

It separates two kinds of cost. Effort — connectors, releases, incidents, security, permissions, support — can be bought late. Standing with third parties, consent provenance and reversibility cannot. And it explains why the obligation grew more expensive rather than less: delegation converts specification gaps into consequences. A missing edge case once produced a wrong screen; it now produces a wrong action in the world.

III · The Company It Forces

Four shorter essays, written after the doctrine was settled, on the institution the argument implies.

7

The Company the Price Builds

Begins from an unusual place: at one-tenth the incumbent price, most of a conventional software company is not a choice but an arithmetic impossibility. It takes each function — sales, implementation, customer success, support, seat pricing, lock-in — names the constraint it was invented to solve, and asks whether the constraint survived. Almost every expensive function of a software company existed to compensate for a product that could not do something.

Then the turn. Accountability, migration and incident ownership do not dissolve and must be industrialised rather than deleted, because a price reached by removing them is not a low price but unpriced risk moved onto the buyer. It locates the real target: not the eighty-five per cent gross margin, which funds work that deserves paying for, but the forty-odd cents of every revenue dollar that incumbents spend on being found and believed. One Tenth is what the price becomes when the go-to-market line is deleted rather than the product.

8

The Migration Factory

Incumbents are protected by something they did not build and cannot lose: the customer’s reasonable belief that leaving would be worse than staying. When replacements took years to build, that was one obstacle among many. When the replacement can be produced in months, it is the only obstacle left standing.

The essay separates implementation, which configures a product, from migration, which carries a living organisation — and shows why a go-live can succeed while a migration fails. It walks eight stages, of which the hardest is reconstructing an operating specification the incumbent never had, from four accounts of the business that will not agree with each other. It argues that shadow operation produces a list of disagreements rather than a pass mark, and that only one of the five kinds is a defect. And it accepts the consequence: a producer who industrialises leaving must make leaving them easy too, because a customer who cannot leave never tests any of the producer’s claims.

9

The Vertical Test

Clears a confusion first: engagement, finance, project management and service are functions, not verticals — jobs recurring across every industry, which is why they look like large markets and have no shared core. A function tells the buyer what the product does. A vertical tells the product what it already knows.

The argument for depth is an asymmetry: the businesses least able to write down their own operating truth are precisely the ones affordable software exists to serve. So the product must arrive already knowing how the work is done and ask only what is different here. Six tests follow — price beyond the job, a visible stack, extractable data, repeatable execution, a bounded accountability tail, and distribution — to be applied as an intersection rather than a score. The sixth decides, because it is the only one AI did not make easier to pass.

10

The Founding Constitution

Converts nine essays of argument into commitments, on the grounds that the failure mode of this thesis is not being wrong but being right and then, one reasonable decision at a time, becoming the thing it described.

Four refusals, each with the reason it will be tested: no customer-specific fork, no customer large enough to rewrite the model, no second vertical before the first core compounds, and no quiet removal of the promise. Four promises: one bill, eight jobs, a tenth of the price, a safe way out — with the obligation inspectable, because a cheap product and an unpriced risk look identical from outside. And one number rather than a dashboard: is the second product materially cheaper, faster and safer to produce than the first, with the threshold published before the first product ships.

Published September 13, 2026

The rules that must be fixed before the first customer can bend them

Nine essays have made an argument. This one converts it into commitments, because an argument that costs nothing to hold is not worth much — and because the specific failure mode of this thesis is not being wrong. It is being right and then, one reasonable decision at a time, becoming the thing it described.

The claim of this essay: every rule below will be tested by somebody offering money to break it, and the ones worth writing down are the few where the offer will be tempting.

1

Why a Constitution and Not Principles

Most companies publish values, and most values are unfalsifiable. Customer obsession, bias for action, integrity: nobody can breach them because nobody can say precisely what would count as a breach. They cost nothing, which is why they are so widely held.

A constitution is different in one respect. It names things the company will refuse when refusing is expensive. A rule that will never be tested is decoration. The test of whether a clause belongs here is simple: can I imagine the meeting where somebody makes a persuasive case for the exception, and can I imagine wanting to agree?

That test removes most of what would otherwise be on the list. It leaves four refusals, four promises and one number.

One structural condition sits behind all of them and cannot be written as a rule, because a rule can be overruled by the organisation that hosts it. This company must remain organisationally separate from any incumbent business whose sales model, customer commitments or existing architecture could override what follows. The Company the Price Builds explained why: the functions being removed are not costs inside the old organisation, they are the old organisation. A constitution written inside a company that can suspend it is a memo.

Figure 1. Nine essays reduce to this.

2

Four Refusals

No customer-specific fork. A capability enters the product only when it is common to a defined segment, expressible as a reusable specification, testable, and operable on the shared core. A customer may configure its own rules. The company will not maintain a branch for one customer, however large.

Why this will be tested: the first meaningful contract will come with a requirement that is almost general. Agreeing once produces revenue and a maintenance obligation that never appears on an invoice. Agree three times and the company is an AI services firm with a product-shaped brochure — which is the failure mode Inside the Foundry named, and the one that arrives disguised as traction.

No customer large enough to rewrite the model. No single customer may hold enough revenue that its departure would change what the company builds. This constrains what can be accepted, not only what is pursued.

Why this will be tested: an enterprise buyer will offer more than the next hundred merchants combined, and will want procurement, a security review, a named account team and a roadmap commitment. Each is reasonable on its own. Together they are the old company shape, purchased at a premium and paid for later.

No second vertical before the first core compounds. Products two and three are adjacent jobs on the same core. Expansion into a new market waits for the number in section four.

Why this will be tested: a second vertical always looks like growth, always looks urgent, and conveniently postpones the only measurement that decides whether the production system is real.

No quiet removal of the promise. The obligation described in The Expensive Last 10% — accountability, migration, incident ownership, consent provenance, reversibility — may be automated, industrialised and made cheaper. It may not be deleted to reach a price.

Why this will be tested: it is the easiest margin in the business and the last one anybody notices. Removing the obligation does not lower the cost; it moves the cost to a customer who has not been told they are carrying it. This is the clause most likely to be breached by accident, through a series of individually sensible economies.

3

Four Promises

One bill. Adjacent jobs share one core, one memory of the business and one invoice. Capabilities remain separately understandable and separately switchable; the customer adds a capability, never another company to manage.

Eight jobs. A defined set of jobs, done properly, on shared foundations. Not a suite pursuing completeness, and not a thin app pretending its neighbours do not exist.

A tenth of the price. Priced against the incumbent bill being replaced, not against each product in isolation. Published, monthly, with no contract required, no seat tax where seats create no cost, and metering that is visible and capped by default.

A safe way out. Full export of data and of the reconstructed operating specification, a documented account of what stops working, and a transition window. Available as a documented capability rather than as a retention conversation.

One operating rule stands behind all four, and it is the one that makes them checkable rather than merely stated: the obligation is inspectable. Which specifications are current and when each was last reviewed. Which dependencies are monitored. What authority the system holds and who granted it. How a consequential action is reconstructed, and how quickly it can be reversed.

At a low price this is not a courtesy. A cheap product and an unpriced risk look identical from outside, and published operating evidence is the only thing that tells them apart.

4

One Number

Everything in this series rests on a claim that can be settled with evidence, and the claim is not that the software will be good. Impressive first products are now within reach of any capable team with agents; 2026 will be full of them, and none of them proves anything about a production system.

The claim is that production compounds. Inside the Foundry set the standard and this constitution freezes it as the single test:

Is the second product materially cheaper, faster and safer to produce than the first — and the third cheaper still?

One test, not a dashboard. The measures in The Company the Price Builds are instrumentation for running the company; this is the condition on which the thesis stands or falls. It resolves into four figures published together: elapsed time from specification to dependable operation, proportion of the product drawn from existing machinery, defects reaching customers, and support minutes per customer per product.

And a commitment about the commitment, because this is where such tests usually fail. The numeric threshold and its date will be published before the first product enters production — before anyone knows whether it will be met. A gate set after the results are visible is not a gate. Once published it does not move, and the current constitutional date is March 2027.

Three conclusions are possible and all three will be stated plainly: the machinery compounded; parts of it compounded but not enough; or a good AI software company was built and a foundry was not. The third is not a small outcome. It is a different one from the one being claimed, and the difference matters more than any individual product.

Two clarifications keep the test honest. It measures the machine, not demand — product-market fit cannot compensate for production that does not compound, and a successful first product proves nothing about the second. And reuse cannot be bought with quality: a threshold met alongside rising escaped defects, rising support load or rising operating cost has not been met.

5

A Debt, Dated

Inside the Foundry closed by promising that the next essay would show the dials. Six essays have followed and none has. The promise is unpaid, and a constitution that lists proof measures while owing an earlier one would be exactly the kind of document this essay opened by dismissing.

So the position, stated plainly: the dials do not exist yet, because the second product does not exist yet. They cannot be estimated, modelled or previewed without becoming the thing they are meant to prevent — a system grading its own homework in advance. The four figures above will be published within one quarter of the second product reaching dependable operation, favourable or not, alongside the assumptions behind them.

Until then, everything in these ten essays is what it has always claimed to be: a description of a machine, offered before the machine has run long enough to be judged.

6

Amendment

A constitution that cannot change is a superstition, and one that changes quietly is decoration. So the rule for changing it: this document is versioned and dated, every previous version stays visible, and an amendment requires a written account of what changed, what evidence required the change, and what follows for customers.

One clause governs the rest. No amendment may retroactively erase a missed commitment. A rule may be abandoned because reality disproved it — that is what evidence is for — but the rule, the failure and the reasoning remain part of the record. Governance is credible only when it preserves its own provenance, which is the same standard this series has applied to every specification it has described.

Three failures would make the document worthless, and readers can watch for all three. Silence: if the second product ships and no numbers follow, the omission is the answer. Amendment under pressure: a rule revised in the quarter it became expensive has not been revised, it has been abandoned with paperwork. Proliferation: if this grows to twenty clauses it has become a policy manual, and the four that mattered will be harder to find than they are today.

It is worth being concrete about how this ends badly, because none of it arrives labelled. The first custom request will look reasonable and small. The first enterprise customer will seem too important to decline. The first migration that needs a project team will be described as an exception. The first support queue will be easier to staff than to eliminate. The first missed gate will invite a better metric. Every one of those arguments will be intelligent, local, and supported by revenue — which is the entire reason the rules have to exist before the arguments arrive.

The series has argued that software production has changed, that the obligation around software has not, that a company built on both propositions must be shaped differently, and that a market should be chosen on distribution rather than on margin. Those arguments are now finished. What follows is arithmetic — and the useful thing about arithmetic is that it does not care how well the essays were written.

Published September 12, 2026

Why depth beats breadth, and how to choose a first market

If software can now be produced cheaply, the obvious move is to produce a lot of it — many products, many categories, wherever an incumbent looks expensive. This essay argues the opposite, and offers a test.

The claim of this essay: the smaller the business, the less of its own operating truth it has ever written down — which means affordable software cannot be general. It has to arrive already knowing how the work is done, and ask only what is different here.

1

A Vertical Is Not a Function

Start by clearing away a confusion that makes this question harder than it is. Customer engagement, finance, project management, service and human resources are useful product domains. None of them is a vertical. They are functions — jobs that recur across every industry, which is exactly why they look like large markets.

A vertical is the operating world in which a function acquires specific entities, rules, exceptions and consequences. Commerce has customers, products, orders, fulfilment, returns, consent and replenishment. A professional firm has clients, engagements, people, capacity, deliverables, time and invoices. A field-service business has jobs, technicians, routes, assets, estimates and parts. Project management describes something all three do. What it means in each is a different subject.

Figure 1. The same job, two different products.

The distinction matters because the architecture is One Core, Many Products. The first choice is therefore not which application to rebuild more cheaply. It is which operating core should become the shared memory for several adjacent jobs — and only a vertical has one. A function has customers in every industry and a core in none.

A function tells the buyer what the product does. A vertical tells the product what it already knows. Which turns out to be the difference that decides whether the price is reachable, for a reason the next section sets out.

2

The Specification Asymmetry

The Expensive Last 10% argued that the scarce input in software is not code and not generic domain knowledge, but a current, sourced, organisation-specific account of how one business operates. That argument has a consequence which points directly at market choice, and it took me some time to notice it.

The businesses least able to produce that account are precisely the ones affordable software exists to serve.

A large company has a compliance function, documented policies, a process owner and an internal system of record. Its operating truth is partial and often stale, but it exists in written form and somebody is responsible for it. A forty-person business has none of that. Its rules live in the heads of five or six experienced people, in a spreadsheet, and in the configuration of whatever system it bought four years ago. Ask it to specify its own returns policy across categories and jurisdictions and you will get a thoughtful answer that is roughly sixty per cent complete, with the missing forty per cent being exactly the exceptions that matter.

This is not a criticism of small businesses. It is a description of what having no spare capacity means. But it disposes of a comfortable assumption — that cheap software plus a capable AI equals a solved problem for the small buyer. Generation was never the obstacle for that buyer. Specification was.

3

Horizontal Asks. Vertical Arrives.

Horizontal software resolves this by handing the problem back. A general work-management tool, a general database, a general automation canvas: each is powerful, and each asks the customer to define its own workflow, its own fields, its own approvals, its own exceptions and its own reports. The product is a capable blank surface, and the customer supplies the operating truth.

That trade works for a company with the capacity to specify. It fails predictably for one without — which is why the graveyard of small-business software is full of tools that were bought, configured halfway, and abandoned at the point where the configuration required a decision nobody had authority to make.

The alternative is a product that arrives with a position:

Here is how a business like yours normally operates. Tell us only what is different about you.

That sentence is the whole argument for vertical depth, and it is worth being precise about what it requires. Not a template. Not an industry-flavoured demo. A default operating specification — the rules, the exceptions, the escalation paths, the things that must never happen, expressed the way Software After Code described, so that the customer’s deviations become edits to something rather than authorship from nothing.

Note where this puts the effort. The expensive work is no longer building the application; it is knowing the domain well enough to write its default. That knowledge is what a vertical producer has and a horizontal one structurally cannot — not because horizontal companies are less capable, but because a default that fits every industry fits none of them.

And it inverts a familiar assumption about scale. Conventional wisdom says horizontal software is the larger opportunity because the market is bigger. In a world where production is cheap and specification is scarce, breadth is the constraint rather than the advantage. The general product must ask. The specific product can already know.

4

Six Tests

Vertical depth narrows the question but does not answer it. Some verticals suit this model and some are traps, and the difference is not the size of the incumbent’s bill. Six tests, and a market has to pass all six.

Figure 2. Six tests for a market. The last one decides.

One: is the price beyond the job? Not whether the incumbent is expensive, but whether the expense is explained by what the software does. The previous essay in this series located the answer: look at what proportion of revenue goes to being found and believed rather than to delivering the product. Where that block is large, the price is funding an organisation rather than a capability.

Two: is there a visible stack? Several products fragmenting one connected workflow, each carrying its own copy of the same foundations. Where the buyer has one tool and it works, there is no App-Stack Tax to remove and the case rests on price alone — which is a weaker case than it appears.

Three: can the data get out? This is the test most likely to be waved through and the one that kills quietly. If the incumbent traps the data, the migration factory does not function, and without migration the price is theoretical: the customer agrees it is better and cannot reach it. A market where switching is impossible is not a cheap market waiting to happen. It is a closed one.

Four: is the execution repeatable? The two-plane architecture requires that most work runs deterministically after intelligence has configured it. A domain where every case is novel — where genuine judgement is required on each transaction rather than on the policy behind it — cannot reach the price, because the cost scales with usage and never comes down.

Five: is the accountability tail bounded? Every domain carries consequence when software acts wrongly. The question is whether that consequence can be carried by a small team with good machinery, or whether it requires the apparatus — the compliance function, the legal exposure, the certifications, the human in the room. Payroll, clinical care and regulated finance all fail this test for a company doing it for the first time. That is not a permanent verdict. It is a sequencing one.

Six: is there distribution, and domain truth? Can this producer reach thousands of relevant buyers at near-zero cost, and does it understand the work well enough to write the default specification? This test decides, because it is the only one AI did not make easier to pass. Production cost collapsed. The cost of being found, believed and understood did not move.

One methodological point, because it is where this framework would most easily be misused. The six are an intersection, not a score. Averaging them produces a number in which a fatal absence is offset by strength elsewhere, which is how a market with spectacular margins and no route to the buyer comes to look attractive. A market like that is a research project. A market with familiar buyers and no shared operating core is a services trap. A market has to pass all six.

5

The Worked Example

Applying the tests without flattery produces an uncomfortable result, and publishing it is more useful than publishing a ranked list of attractive markets.

On price and fragmentation, several verticals score better than commerce engagement. Field service is a clear case: per-seat pricing that compounds as a business grows, and a standard small-operator stack of scheduling software plus accounting plus payroll plus messaging plus a review tool — five products, one connected workflow from enquiry to payment. Professional services scores similarly. Both have fatter margins to attack than commerce.

Both fail test six. No route to the buyer, and no domain truth in the building.

So the first market chosen here is commerce engagement for smaller merchants, and the honest reason is the sixth test rather than the first. There is an existing customer base, a marketplace where those buyers already shop, and real operating knowledge of how merchants work. It is not the fattest market available. It is the one that can be reached without paying for the privilege — and at one-tenth pricing, a market that must be bought into is not a market at all.

State that plainly rather than dressing it up, because the alternative invites a fair question. A producer who claims its first vertical is objectively the best opportunity in software is either lucky or not being straight, and the second is more likely.

6

Attractive Markets That Are Not First Markets

Applying the tests across other categories is useful for a reason that has nothing to do with picking the next one. Each failure is a different kind, and seeing four of them makes the framework legible in a way the abstract version is not.

Field service and trades. An obvious stack across lead capture, scheduling, dispatch, estimates, payments, communication and reviews, with per-seat pricing that compounds as the business grows. It passes tests one and two more clearly than commerce does. It fails on distribution and domain truth, and the work is mobile and physical in ways that raise the support burden considerably.

Small-business finance operations. Large bills and highly repeatable workflows in receivables, payables, reconciliation and cash visibility. The failure is test five: correctness requirements are severe, incumbent trust is deep, and the consequences of a wrong automated action are immediate and legal. The general ledger is a poor place to learn accountability.

Project and work management. Easy to build, easy to distribute, apparently enormous. That is the problem. These are blank canvases — the customer becomes the specifier, which is the failure mode of section three — the category is crowded, and general-purpose agents will absorb much of the surface. A function without a vertical underneath it.

Regulated professional practice — healthcare, legal, clinical. Rich margins and strong vertical data models, and they fail on almost everything the previous essay described: relationship selling, formal validation, specialised liability and human support expectations. The company the price builds cannot serve them, which is not a criticism of either party.

A fat incumbent margin does not create a right to win, and a right to build does not create a right to enter. These are sequencing verdicts rather than permanent ones — several become reasonable for a producer that has already proved its machinery somewhere else.

7

Why the Second Vertical Is a Trap

The tests above are a method for choosing markets, which makes it tempting to run them across a dozen categories and build a sequence. That would be a mistake, and the reason is the one thing this series has committed to measuring.

Inside the Foundry set the standard: a production system is judged by whether each product makes the next one cheaper, faster and safer to produce. A second vertical resets that measurement to zero while looking like progress. New domain truth, new connectors, new regulatory context, new buyers, new default specification. Revenue grows, headcount grows, and the number that decides whether a foundry exists never gets tested.

So products two and three are adjacent jobs on the same core — different jobs, same customers, same identity, catalogue, orders, consent and workflow. That is the arrangement The App-Stack Tax called One Core, Many Products, and it is the only arrangement in which reuse can be observed rather than asserted.

Expansion into a second market is not the proof that the machine works. It is the reward for having proved it. A company that expands first has chosen the version of the story that cannot be falsified — which is comfortable, and worth nothing.

Which is why this essay publishes a method and only one market. The method is durable and belongs to any reader who wants it. The ranking of markets, wedges, prices and timing is a plan, and plans belong where they can change when the first ten customers teach you something.

The discipline of a vertical strategy is not how many markets it can identify. It is how many attractive ones it can decline while the first is still teaching the machine.

Published September 11, 2026

Why the next software battle will be won by making it safe to leave

The Foundry Price ended with seven questions a buyer should ask before signing a renewal. This essay is the operational sequel. You asked the questions, the answers were poor, and now there is a harder problem: how does a business move?

The claim of this essay: when software becomes cheap to build, the binding constraint is no longer building the replacement. It is moving a living business into it without breaking anything — and whoever industrialises that will hold a more valuable position than whoever ships the better feature.

1

The Moat That Is Not a Feature

Ask a finance director why an expensive contract was renewed and the answer is rarely that the product is excellent. It is some version of: we looked, and leaving seemed worse.

Unpack that sentence and it contains a specific set of fears, each reasonable. The data may not come out complete. Configuration built over six years is undocumented, and nobody remembers why the third rule exists. Integrations will break in ways that surface a fortnight later. Workflows nobody described will turn out to have been load-bearing. Historical records may not transfer, and somebody will need them during an audit. Staff will resist a system that does the same job differently. And underneath all of it, one person will be responsible if the transition goes badly — and that person is usually the one recommending the change.

None of those fears is about the incumbent’s product. They are all about the transition. Which means the incumbent is protected by something it did not build and cannot lose: the customer’s reasonable assessment that the disruption exceeds the saving.

This has always been true. What changes it is the collapse in production cost. When building a competitive replacement took three years and forty engineers, migration difficulty was one obstacle among many and not the largest. When the replacement can be produced in months, migration becomes the only obstacle left standing — and therefore the one worth industrialising.

There is a useful precedent. Mobile telephone numbers were portable long before most people used the right to switch; the point was never that everybody moved, but that staying became a decision rather than a default. A migration factory does the same thing to a software renewal. Its value is not measured only in customers who arrive. It is measured in the moment a buyer stops treating the incumbent as fixed.

2

Implementation Is Not Migration

The software industry has a word for the work of getting a customer onto a new system, and the word is wrong. Implementation describes configuring a product to meet a customer’s requirements. It begins with the new system’s needs: which fields must be populated, which workflows configured, which integrations connected, which users trained. It is a project, it is scoped by the vendor, and it is priced.

Migration begins from the other end. It begins with what the customer cannot afford to lose — and the customer usually cannot say what that is, because most of it was never written down. The undocumented exception. The suppression rule added after an incident in 2022. The report one department depends on that nobody else knows exists. Implementation asks what the new system needs. Migration asks what the old one was doing.

Implementation	Migration
Begins with the new product’s configuration	Begins with the customer’s current operating reality
Collects the fields and settings required	Discovers undocumented workflows, exceptions and dependencies
Optimises for go-live	Optimises for continuity, evidence and reversal
Treats disagreement as a configuration issue	Treats disagreement as information about policy or history
Ends when the product is live	Ends when the business is stable and the way back is known

Table 1. Implementation configures a product. Migration carries a living organisation.

The distinction is not academic, because the two produce different failure modes. A go-live can succeed while the migration fails. The screens work, the records exist, the project is signed off — and a consent rule was simplified, a refund exception vanished, a report no longer reconciles, and one connector silently stopped sending a class of event. The new system is live. The old operating truth did not arrive.

A failed implementation produces a system configured wrongly, which is visible and fixable. A failed migration produces a system that works perfectly and quietly does something the business did not intend — the silent kind of failure that The Expensive Last 10% described, discovered later, by its consequences.

This also explains why migration has never been a product. It has been a professional-services engagement: senior people, spreadsheets, discovery workshops, a project plan, a risk register, and a price that often exceeds the software’s annual cost. That was rational when discovery could only be done by expensive humans interviewing other humans. It is what makes migration the obvious thing to industrialise now, because most of that discovery is reading systems, not reading minds.

3

The Machine

A migration factory is a repeatable production line, not a bespoke project. Eight stages, and the middle two carry the difficulty.

Figure 1. The migration factory. Steps three and four are where the value sits.

Discover. Connect to the incumbent and establish what is running: entities, volumes, configuration, automations, integrations, permissions, retention rules, and — the part that matters — what is running that nobody described. Discovery reads the system rather than interviewing the organisation, which is why it can be done in an afternoon rather than a fortnight.

Extract. Records, configuration, workflow definitions, permissions, templates, history, consent records, suppression state and audit trail, in a form that can be inspected rather than merely loaded. Data export without configuration export moves the nouns and loses the verbs.

Reconstruct. This is the hard one and the whole argument turns on it, so the next section takes it alone.

Reconcile. Discovery always surfaces contradictions: two rules that disagree, a policy documented one way and running another, permissions granted to people who left. Most migration projects quietly resolve these by picking one. A factory does the opposite — it surfaces them and requires somebody with standing to decide, because as The Expensive Last 10% argued, choosing between two contested truths is an institutional act and not a technical one.

Shadow. The new system runs alongside the old, receiving the same inputs, acting on nothing. This is the step that removes the fear, and it is the reason the sequence can be self-serve: nobody has to trust the replacement before watching it be right.

Certify. Equivalence has to be defined before it is tested, or the comparison becomes an argument. Which outputs must match, within what tolerance, over what period, and what constitutes an acceptable difference rather than a defect. A migration that cannot state in advance what would count as success is not a migration; it is a hope.

Switch. By segment rather than by weekend. One customer group, one workflow, one region at a time, with the old system live behind it.

Reverse. A route back that stays open, and is tested rather than assumed. Reversal is not the inverse of switching; it is a designed capability, and it has to exist before anybody needs it.

4

Reconstructing a Specification That Never Existed

Everything above is engineering except the third step, which is closer to archaeology.

The incumbent system does not contain a specification. It contains behaviour — configuration, rules, automations, exceptions and accumulated workarounds that together encode how the business operates, without anywhere stating it. Nobody wrote it down because nobody had to; the system was the statement.

Worse, there is no single account to work from. Four of them exist and they disagree: the written policy, the incumbent’s configuration, what the system observably does, and what the experienced people say happens when the normal rule does not fit.

Figure 2. The reconstruction step resolves four disagreeing accounts into one.

So the reconstruction step converts behaviour into an executable account: which rules are in force, what they do, which are legal requirements and which are preferences, which exceptions have been accepted, who may override, what happens when two rules conflict. *This is the same artefact Software After Code called the specification, produced backwards* — derived from a running system rather than authored ahead of one.

Two properties make it difficult, and both were named in the previous essay. Provenance is missing: the system knows what to do and not why, so a rule cannot be safely changed by anyone who does not already know its origin. And habit is indistinguishable from policy in the artefact itself — a workaround added for a supplier who no longer exists looks exactly like a compliance requirement. Migrate without separating them and the new system inherits the folklore with the same authority as the law.

Which is why the reconstruction step produces two outputs rather than one: the specification, and a list of things the organisation must now decide. The second output is often more valuable than the migration. A business that has never seen its own operating rules written down usually discovers, at this point, several it would not have chosen.

And this is the durable asset. The data lands once and is then just data. The reconstructed specification is what the customer keeps, what the system is regenerated from afterwards, and what makes the next change safe — which is the recompile property from Software After Code, and it cannot exist without this step.

5

Disagreement Is the Product

Shadow operation is the bridge between a plausible replacement and an authorised one, and its output is not a pass mark. It is a list of differences — every case where the two systems would have done something different under identical conditions.

The temptation is to call all of them defects and fix them until the systems agree. That destroys precisely the information the exercise exists to surface, because the differences fall into five categories and only one of them is a defect.

Kind of disagreement	What it requires
The replacement is wrong	Correct the specification and add a permanent test
The incumbent is wrong	Confirm the old behaviour should not be preserved out of familiarity
The data differs	Reconcile source, timing, identity or historical state
The policy is ambiguous	An authorised person decides, and the decision is recorded with its provenance
Both are acceptable	Define the boundary within which either action is allowed

Table 2. Shadow operation converts uncertainty into a finite set of decisions.

The second row is the one customers find hardest and value most. A difference is not automatically an error in the new system; sometimes the incumbent has been doing something wrong for four years and nobody noticed because nothing existed to compare it against.

Certification, then, does not mean the two systems agree. It means the organisation understands why they differ and has authorised the new behaviour — across the ordinary path, the rare and consequential exceptions, the permission model, silent-failure detection and the route back.

Which connects migration to the authority ladder in Software After Code. The replacement begins by observing, then recommending, then preparing, then acting after approval, and only later operating within policy. A migration is not complete when the data arrives. It is complete when authority has been earned.

6

Switching Without the Weekend

Large migrations are still narrated as heroic weekends: freeze on Friday, move everything, test through the night, declare victory on Monday. The story persists because projects are organised around dates. Businesses are organised around continuity.

Progressive switching aligns with the second. Move one capability whose boundaries are clear, or one location, one cohort, one workflow, keeping the incumbent as the fallback for everything else. Compare operating results, support load and exceptions. Expand only where the evidence holds.

This changes the economics as well as the risk. The customer receives value before the whole estate moves. The producer discovers where its own machinery is weak while the blast radius is small. And the incumbent contract can be reduced in stages rather than terminated through one all-or-nothing negotiation — which matters, because that negotiation is often the real reason a switch never starts.

It also permits an ending the industry rarely admits to. The end state need not be total replacement. Some customers will keep the incumbent as a system of record and move workflows, intelligence or selected capabilities out around it. Migration is not ideological purity; it is the disciplined movement of utility to the architecture and the price that serve it best.

7

The Argument Only Works If It Points Both Ways

There is an obvious objection, and any reader will have arrived at it. A company that industrialises leaving expensive software has built a weapon it will eventually want to point away from itself. The migration factory attacks the incumbent’s lock-in on Monday and becomes the new lock-in by Friday.

The only answer that survives is to make exit a shipped feature: full data export, the reconstructed specification exported with it, a documented list of what will stop working, connector inventory, the authority granted to each agent, and a transition window during which both systems can run. Not on request. Not as a retention conversation. As a documented capability with a page describing it.

This sounds like commercial self-harm and is closer to the opposite, for a reason that fits the rest of this series. The company has argued that its price is honest, its obligation is inspectable and its value is continuing. A customer who cannot leave never tests any of those claims, which means the company never learns whether they are true. Retention through lock-in is a mechanism for not finding out.

There is also a plainer argument. A buyer deciding whether to enter a system is making a bet on how hard it will be to reverse. Lowering the cost of leaving lowers the cost of arriving — which, for a company with no salespeople to overcome hesitation, is not a philosophical position. It is the acquisition mechanism.

8

What This Changes

Three consequences, and they run in increasing order of size.

For the buyer, the renewal conversation changes shape. The Foundry Price argued that the moment leaving has a price, staying has a negotiation. Migration machinery is what converts that from advice into a number — and the number is useful whether or not anybody switches.

For the producer, migration stops being a cost of sale and becomes the product’s front half. It is the first thing a customer experiences, it is where the operating truth is captured, and it is the step that decides whether everything afterwards works. A company that treats migration as onboarding has misunderstood which part of its product is load-bearing.

And for the market: incumbency stops being a position and becomes a performance. Software companies have long enjoyed a protection they did not earn and could not lose — the accumulated difficulty of leaving. When that difficulty is industrialised away, the only remaining reasons to stay are the ones a vendor has to keep earning: the product is good, the price is honest, and somebody is answerable when it fails.

One discipline keeps the whole thing from collapsing back into what it replaced, and it should be stated because the pressure is predictable. A difficult migration will invite bespoke services. A valuable customer will be offered a project team. The revenue will look good, and the migration factory will quietly become an implementation practice again. The rule is the same one that governs everything else here: custom work is permitted only when it produces a reusable mapping, connector, specification or component. Measure it accordingly — human hours per migration, proportion of configuration reconstructed without help, disagreements resolved before switching, incidents after it.

The most valuable thing to build in software may not be the replacement. It may be the road out.

Published September 10, 2026

What one-tenth pricing forces a software company to become

The earlier essays in this series described a production system. The Software Foundry named the collapse in production cost, The App-Stack Tax the waste it exposes, The Foundry Price the number that follows, and Inside the Foundry the machinery that makes the number sustainable. Software After Code and The Expensive Last 10% then widened the argument beyond any one company.

None of them described the company. That is this essay’s subject, and it has an unusual starting point.

The claim of this essay: at one-tenth the incumbent price, most of a conventional software company is not a choice. It is arithmetically unaffordable — and the interesting question is which of its functions were solving a problem that has now gone, and which were solving one that has not.

One disclosure belongs at the front rather than in a footnote. I run a company built on the model this essay describes as obsolete: enterprise selling, implementation, customer success, the whole apparatus. That is not an argument against the analysis, but it is the reason the analysis has a conclusion I would rather avoid — a company of this kind cannot be built as a product line inside a company of the other kind. The functions being removed are not costs to be trimmed. They are the organisation.

1

SaaS Industrialised Distribution, Not Production

The cloud transition is worth revisiting, because it is routinely described as the moment software was transformed and it was nothing of the sort. It changed how software was delivered and paid for: browser instead of installation, subscription instead of licence, shared infrastructure instead of separate deployments, continuous release instead of the eighteen-month upgrade. Real changes, and they built an industry.

But look at what the company behind the software still contained. Engineers writing and maintaining code by hand. Product managers translating customer needs into specifications nobody enforced. Salespeople finding buyers. Consultants making the product work after it was bought. Customer success teams driving adoption that should have happened unaided. Support desks answering questions the product could have answered. Finance constructing contracts complicated enough to require explanation. And managers coordinating all of them.

SaaS put software in the cloud. It left the company that made the software almost exactly where it was. Production stayed artisanal, and the organisation stayed the shape that artisanal production requires.

That is the structure now under pressure — and the pressure does not come from AI directly. It comes from the price. Which is worth stating as a reversal of the usual order, because most software companies discover their price at the end: build the product, hire the organisation needed to sell and support it, add the expected margin, and arrive at the number the customer pays. The invoice is the last layer of the company. Begin instead from the buyer’s bill and work backwards, and the question becomes which company can exist inside that number.

The price is not the last decision a software company makes. It is the first, and it writes the organisation chart.

2

What the Price Forbids

Take the arithmetic seriously for a moment. A product replacing an incumbent bill of a thousand dollars a month cannot carry a salesperson: the commission alone exceeds the revenue. It cannot carry an implementation consultant, a success manager or a support desk staffed to answer routine questions. These are not decisions about company culture. They are line items the price has already ruled out.

Which turns out to be the useful way into the question, because each of those functions was invented to compensate for a specific constraint. Name the constraint and the honest question becomes: is it still there?

Function	The constraint it solved	What replaces it
Sales team	The product could not be found or understood unaided	Borrowed distribution and a self-serve diagnostic
Implementation	The product could not configure itself	Migration machinery, run by the customer
Customer success	Adoption failed by default	The product observes its own adoption and intervenes
Support desk	The product could not explain or repair itself	Telemetry, diagnosis, guided repair, reversible change
Custom roadmap	Change was expensive, so it was rationed and traded	Reusable specifications and shared machinery
Annual contract	Revenue had to be secured against churn the product could not prevent	Monthly terms, and value that survives the option to leave
Per-seat pricing	Value was assumed to track headcount	Flat capability pricing with visible, capped metering
Lock-in	Retention could not be earned every month	Portability, and a documented way out

Table 1. Each function answered a real problem. The question is which problems survived.

Read the middle column as a group and a pattern appears. Almost every expensive function of a software company existed to compensate for a product that could not do something. It could not be found. It could not configure itself. It could not explain its own failure. It could not be left safely, so it had to be locked. The organisation was scaffolding around the product’s incapacities.

That is why the removals are not austerity. Cutting the people while leaving the work behind produces an understaffed SaaS company, not a different kind of company — and the failure is not immediately visible, which is what makes it dangerous. A company that deletes the sales team without solving discovery has not become efficient; it has become invisible.

The substitution is also stricter than putting AI in front of each department, and the distinction is worth being blunt about. A support bot in front of a product that cannot observe itself merely automates the apology. A coding agent inside a company that still builds a separate architecture for every product produces inconsistency faster. A self-serve trial attached to a six-week migration is not product-led growth; it is a sales funnel with the first meeting removed.

Which gives the operating standard: no routine task should require another permanent department. When recurring human work appears, the first question is not whom to hire. It is what the product or the production system failed to absorb.

3

What the Price Cannot Delete

Now the turn, and it is the part of this argument that matters most, because the previous section read alone describes a company that has quietly transferred its risk to its customers.

Three things do not dissolve. Accountability — somebody must be answerable when the software acts wrongly, and no volume of automation supplies that. Migration — a customer arriving from an incumbent is moving a living business, which is the subject of the next essay. Incident ownership — when a connector fails silently or an action goes out that should not have, a named person must own it at an inconvenient hour.

The Expensive Last 10% argued that these obligations are what a producer sells once code becomes abundant. It follows that a low price achieved by removing them is not a low price. It is unpriced risk moved onto the buyer’s side of the arrangement, where it will be discovered later by somebody who did not know they had bought it.

So the discipline is precise, and it is easy to state and hard to hold: industrialise the obligation; never delete it. Deflect the routine question through the product. Keep a named human path for consequential failure. And make the obligation visible rather than asserted — which specifications are current, which dependencies are monitored, what authority the system holds, how an action is reconstructed and reversed. At a low price this is not a nicety. A low price is exactly what an unpriced risk would look like from outside, and inspectable evidence is the only thing that distinguishes the two.

4

A Small Institution Governing a Large Machine

What remains is a company organised around a much shorter list of human responsibilities: deciding which problems deserve solving, writing the operating specifications, designing the architecture and the boundaries of authority, judging whether the system is correct, governing exceptions, holding customer trust, and allocating capital.

Agents do the translation between those decisions — specification to implementation, implementation to tests, behaviour to documentation, telemetry to diagnosis, question to answer, usage to intervention. This is not a conventional company with AI assistance. It is a small human institution governing a much larger machine workforce, and the distinction shows up in what the company does when demand grows.

A conventional software company answers growth by hiring: more account executives, more implementation, more success, more support. Each increment of revenue costs an increment of people, which is why software companies get less efficient as they get larger and why their prices must rise to fund the organisation their prices created.

The alternative is to answer growth by compounding machinery. A connector built once serves every product. A migration mapping improves every future migration. A support resolution becomes an automated playbook. A domain rule becomes a reusable specification. A security fix propagates across the estate. The operating question stops being how many people are needed to reach the next ten million, and becomes which reusable capability would make the next ten million need fewer people than the last.

The phrase “small team” invites a misreading worth heading off. Headcount is not the doctrine, and there may never be a ten-person billion-dollar software company in any market worth entering — that number is theatre. The meaningful curve is different: human intervention per customer, per product and per consequential action, falling as the company learns.

Which sets the rule for hiring, and it is not a headcount target. Add a person when the system faces a class of judgement it does not possess — a new vertical’s domain truth, a new category of risk, a new regulatory context. Never add one because revenue grew.

5

Product-Led from Discovery to Departure

Most companies described as product-led are self-serve at the easiest moment only. A user starts a trial without speaking to anyone, and then meets a human at migration, at configuration, at adoption, at expansion, at support and at exit. That is not a product-led company. It is a company whose lead form has been replaced by a button.

At this price the whole relationship has to be product-led, and it is worth naming the stages because each one is a place where a conventional company inserts a person.

Figure 1. Each stage is somewhere a conventional company inserts a person.

Discovery comes through an existing base, marketplaces, partners and word of mouth — borrowed, because acquisition cost is the one thing AI did not reduce. Diagnosis should happen before purchase: connect the incumbent, show which jobs are used, expose what is being paid for and identify what can move safely. The customer should reach first value before a salesperson would ordinarily have qualified the opportunity.

Migration and shadow operation sit at the centre of this sequence rather than at its edge, and they are the subject of the next essay. The organisational point is enough here: if moving a customer in requires a project manager, a consultant and a weekly call, the price does not survive contact with adoption.

Departure completes the discipline. Data, configuration and the reconstructed operating specification should be exportable without a retention conversation. Easy exit is not commercial naivety. It is what forces the product to hold customers through continuing usefulness rather than captivity — and a company with no salespeople to overcome hesitation needs the entry decision to feel reversible.

6

Pricing Without a Growth Tax

The headline number matters less than the pricing constitution behind it, because a nominally cheap product becomes expensive through seats, contacts, modules, activation fees, compulsory annual terms and opaque usage. The buyer experiences the invoice, not the pricing page.

So: published prices, monthly terms, no quotation for the standard product, no activation fee for ordinary use, and no per-seat or per-contact charge where those units create no real cost. A growing small business should never fear its own success on the bill — which is precisely what per-seat pricing was designed to do, and the reason flat-rate competitors keep winning in categories where headcount and value have come apart.

Where variable cost is real — messages, storage, payments, model calls — metering must be visible, capped by default and paired with budget controls. A low entry price with an unpredictable usage bill is not affordability. It is uncertainty relocated to the customer.

And One Tenth is relative to the incumbent bill being replaced, not a universal figure. A capability at $150 replacing $1,500 of fragmented software is faithful to the idea. A product at $10 that consumes twenty minutes of human support each month is not, whatever its price says.

7

The Economics: The Target Is Not the Margin

It is tempting to describe the opportunity as attacking fat gross margins, and the numbers invite it: monday.com reported an 89% GAAP gross margin for 2025; HubSpot generated roughly $2.62 billion of gross profit on $3.13 billion of revenue; Veeva’s subscription gross margin exceeded 86%.

That reading is wrong, and this series has already argued why. Gross margin at that level funds delivery, security, reliability and the obligation — the things The Expensive Last 10% insists deserve to be paid for. Attacking gross margin means attacking dependability, which is the one thing that cannot be attacked.

The fat is one line lower. HubSpot spent $1.38 billion on sales and marketing in 2025 — about 44 cents of every revenue dollar on being found and believed. monday.com spent roughly $631 million on the same line. That block is not delivering software to anyone. It exists because the product could not be found or understood unaided, which is the constraint the first row of Table 1 describes.

Figure 2. The block being removed is the one beside delivery, not delivery itself.

So One Tenth is not a discount financed by optimism. It is what the price becomes when the go-to-market line is deleted rather than the product. That formulation matters, because it is falsifiable: a company that removes the sales organisation and does not find distribution has not built a cheaper product, it has built an unfound one.

The constraint runs the other way as well, and it is the reason this cannot be assumed. Inference is a cost that scales with usage rather than with customers — the opposite shape from the software industry’s foundational economics — and AI-native gross margins are settling well below the historic norm. The two-plane architecture from Software After Code is the structural answer: intelligence configures the workflow, deterministic execution runs it. Delivery cost is the one line that gets harder in this model, which is why it has to be engineered from product one rather than repaired later.

8

What Management Watches

A company shaped this way cannot be run on the conventional dashboard. Bookings, pipeline, quota attainment and utilisation all measure an organisation this company does not have. What replaces them falls into four groups, and they are worth naming because they are how the model is disproved as well as proved.

Production. Time from specification to deployed capability. Proportion of a new product drawn from existing machinery. The cost of product two relative to product one.

Adoption. Time from connection to first useful output. Migration completion without human help. Retention at eight weeks. Capabilities activated per customer.

Economics. Gross margin after the full cost of keeping the promise — inference, infrastructure, messaging and human minutes. Support minutes per active customer. Acquisition cost by distribution route. Revenue per permanent employee.

Authority. Distribution of actions by authority level. Human interventions per thousand agent actions. Proportion of consequential actions that can be reconstructed. Reversal rate. Time to detect a silent failure.

The last group is the unfamiliar one, and it is the group that keeps this company honest. A conventional dashboard measures how much software was sold. This one measures how much organisational labour the software replaced without weakening the promise — and the two can move in opposite directions, which is precisely why both need watching.

These numbers also guard against a specific kind of decay. A large customer will offer to pay for a branch. A partner will ask for a special margin. Someone will promise a roadmap item to close a quarter. A support queue will look easier to staff than to eliminate. Every one of those decisions is locally rational and collectively fatal, and none of them shows up on a conventional dashboard until the company has already become something else.

Inside the Foundry committed to publishing production numbers once they exist. That commitment stands, it is not yet payable, and the final essay in this series dates it.

9

What This Model Is Bad At

An essay describing a company one intends to build is worth little unless it says where the company should not be chosen, so: this model is a poor answer for any customer that needs bespoke work, institutional procurement, a named human in the room during evaluation, contractual liability at enterprise scale, or a roadmap shaped by their own requirements. Those buyers are well served by the incumbent model, which is why the incumbent model exists.

It also does not generalise across every domain. Where regulation is heavy, where physical operations intrude, where a single error carries severe consequence, or where buyers cannot purchase without institutional selling, the obligation cannot be industrialised by a small team — at least not yet, and not by a company doing it for the first time. The defensible claim is narrower than the exciting one:

AI makes a radically smaller and more automated software company possible in domains where the work is repeatable, the data is reachable, migration can be industrialised, and customers can buy without being sold to. Where a domain fails those tests, the old company shape is still the right one. Which domains pass is the subject of the ninth essay.

The great software companies of the subscription era were built by organising large numbers of people to create, sell, implement and support code. The companies that follow may be built by organising a small number of people to govern specifications, machinery and authority. Their advantage will not be that they employ fewer people. It will be that each additional product, customer and market requires fewer than the last.