Rajesh Jain

Published September 15, 2026

Two large and rapidly growing sources of avoidable cost — and the three places the loop can be cut

Part I: The Tax

1 

The double payment

Companies have learnt to negotiate the price of almost everything. Media rates, software licences, agency retainers, implementation fees, freight, headcount — each has an owner, a benchmark and somebody measured on bringing it down. Yet two large and rapidly growing sources of avoidable cost pass through most organisations every year with remarkably little argument.

The first is what a company pays to reach customers it already has. The second is what it pays to rebuild software foundations it has already bought. Both are entirely visible. Neither is usually seen for what it is, and in most organisations neither has been put in front of a board as a number.

The pattern underneath both sounds implausible when stated plainly. Companies repeatedly pay for value they have already created. They acquire a customer, earn an identity, accumulate a history and establish permission to make contact — then, when attention weakens, pay an outside platform to put the same person back in view. They buy software application by application, each arriving with its own copy of the same foundations — then pay to integrate the copies and hire people to keep them aligned.

The two payments look nothing alike. One sits in marketing and is priced by auction; the other sits in technology and is priced by licence. Economically they are the same act: paying a second time for an asset that should have compounded after the first payment. A customer relationship ought to become more valuable with every interaction. Software machinery ought to make the next capability cheaper to produce. Instead both are repurchased.

The word tax is used here in its economic sense rather than its statutory one: a recurring toll that rises with the level of business activity, is treated as unavoidable, and is rarely examined as a category. Nothing in the argument depends on the word. What matters is that both payments behave that way, and that neither has a name. The Reacquisition Tax is what a business pays to reach people it already knows. The App-Stack Tax is what it pays to rebuild foundations it has already funded.

Figure 1. Two payments leaving the business for assets it already holds.

2 

Paying to reach people you already know

The mechanism is so ordinary that it takes an effort to see at all.

A customer bought something eighteen months ago. Their address, their order history and, in most cases, a valid permission to contact them are all in the database. At some point they stopped opening what the company sent, and the company — noticing the gap in revenue rather than the gap in attention — buys them back through a platform which holds the same address the company already has, at a price set by an auction the company also pays to enter.

The precision that matters here is easy to lose, and losing it is exactly how the tax stays invisible. The business has not lost the customer’s identity. It has lost their attention. Those are different failures with different remedies and different costs, and treating the second as though it were the first is what turns a relationship problem into a media budget. The identity was never lost. The attention was — and the tax is what a company pays somebody else to supply the attention it stopped earning.

Platforms are exceptionally good at finding intent, and that competence is what makes the tax feel like ordinary growth. The platform can tell when somebody is browsing, comparing or returning to the category, and it reports the resulting conversion with confidence. The dashboard shows a new customer acquired at an acceptable cost. The dashboard is not wrong; it is answering a narrower question than the one that matters. The same person can be labelled new by the channel and known by the company at the same moment. The channel takes the credit and the profit and loss statement absorbs the duplication.

This is not an argument that paid acquisition is waste. A business with no prior relationship to a buyer has to pay somebody to create one, and that money is well spent. The avoidable portion is narrower: the part of the acquisition budget landing on people already in the customer file, still contactable, and reachable at a marginal delivery cost close to nothing — if only they were still paying attention.

Two honest caveats. Being present in a database is not the same as being contactable: permissions lapse, addresses decay and deliverability is earned rather than assumed. And low marginal delivery cost is not zero cost — the message still has to be worth opening, which takes data, judgement and people. The claim is not that owned contact is free. It is that it is an order of magnitude cheaper than renting the same person back, and that the gap is rarely calculated.

3 

Paying for the same foundations eight times

A mid-sized consumer business runs somewhere between eight and twenty applications to serve its customers. Each of them, underneath the part that makes it distinctive, contains the same things: a model of the customer, a model of the product, a record of orders, a consent state, a workflow engine, a reporting layer.

Every one of those foundations was built by the vendor, and every one is charged for. The buyer pays for the same substructure once per supplier, and uses only the thin layer on top where the suppliers differ from each other.

The subscriptions are the visible part and, in most companies, the smallest. The true bill is eight subscriptions, plus the integrations between them, plus the work of deciding which system is right when two disagree, plus the people employed to hold the arrangement together. The last of these is often the largest and is the least likely to appear in any assessment of what the software costs, because it is filed under headcount rather than under software.

The largest consequence may not be the bill at all. It is the loss of organisational speed. A simple change becomes a cross-application project. A new workflow waits on three internal teams and four suppliers. A question about a single customer produces five answers, and somebody has to decide which one the business will act on. The stack delivers a great many capabilities while steadily reducing the company’s ability to behave as one system — and that cost appears on no invoice at all.

The same qualification applies as before, and it needs to be operational rather than gestural, because otherwise this reads as an argument against buying the best available tool — which it is not. Two questions, applied to any application at renewal.

—  Does it contribute a distinctive capability the business could not otherwise obtain?

—  What share of its cost is that capability, as against rebuilding identity, catalogue, workflow, permissions and reporting underneath it?

An application that passes the first is specialised software and worth its price. An application that fails the second is mostly a copy of foundations already funded, sold at the price of the feature on top. The App-Stack Tax is the second category. Nothing here argues against the first.

4 

Visible as cost, invisible as waste

Neither tax is hidden. Both are entirely present on the profit and loss statement, in categories any finance function can read: acquisition cost, marketplace commission, software subscriptions, implementation, integration, operations headcount. Anybody can see the money. What nobody can see is that a portion of it did not need to be spent.

Figure 2. The taxes are not concealed. They are distributed across categories that each look reasonable in isolation, and each of which already has a sponsor.

The finance function is well equipped to ask whether a cost is too high. It has no instrument for asking whether a cost needed to exist. Those are different questions, and only the first has a procedure attached to it. A 12 per cent reduction in the acquisition budget is a negotiation anybody knows how to run. A question about which share of that budget is buying back people the company already knew has no owner, no method and no meeting.

So the position is this. Both taxes are visible as cost and invisible as waste. No budget line is called money we did not need to spend. Nobody’s objective includes reducing it. No supplier has any interest in pointing it out, since both taxes are somebody’s revenue. And because the total is distributed across half a dozen categories that each look defensible on their own, no single review has ever seen the whole of it in one place.

There is an organisational version of the same asymmetry, and it is the more stubborn of the two. The media team is accountable for the return on the next campaign, not for whether that campaign reached people the business should still have been able to reach itself. The application owner is accountable for whether the tool works, not for whether seven other tools already contain its foundations. Every participant can be locally correct while the company is globally wasteful — and because every participant is locally correct, every participant can defend their position without lying, which is why these conversations never resolve.

There is a third reason, and it is the least comfortable of the three. Removing either tax reduces somebody’s budget, vendor estate or organisational standing before it improves the company’s profit. The saving arrives later and lands on the profit and loss statement; the loss arrives immediately and lands on a person. That asymmetry is enough to keep a well-run business paying both taxes indefinitely, and no amount of analysis dissolves it.

Challenging either tax therefore requires something no review is designed to do: change the unit of analysis. Stop asking whether this campaign performed or this application delivered its features, and ask whether the payment needed to exist.

Figure 3. Both questions are reasonable. Only one of them has an owner, a method and a place on an agenda.

Companies scrutinise what has been named. That is the entire argument for naming these.

Key points

—  Both taxes are the same act: paying a second time for an asset that should have compounded.

—  The identity was never lost. The attention was.

—  The software bill is the visible edge; the larger costs are headcount and lost speed.

—  Both are visible as cost and invisible as waste, and every participant is locally correct.

—  Removing either tax costs somebody their budget before it improves anybody’s profit.

Part II: The Loop

5

Both were rational when they started

It would be convenient to treat all of this as negligence. It is not, and an essay that says so will be admired and not forwarded. Both taxes began as sensible answers to real constraints, and neither was a failure of attention at the time it was incurred.

The decision	The constraint that made it right	What changed
Buy the audience	A customer who had stopped opening was, in practice, unreachable. Nothing in the owned channel could win the attention back, so the attention had to be rented from whoever had assembled it.	The owned surface became capable of earning attention again, and the effect of an intervention became measurable against a control rather than asserted.
Buy the eighth application	Eight jobs needed doing and nobody sold a ninth thing that did all of them. Assembling a stack was not a preference; it was the only route to the work getting done at all.	Producing software stopped being the expensive part, which makes a single system covering several jobs buildable at a price a small business can pay.

Table 1. Both taxes were rational responses to constraints that no longer hold.

That is a different accusation from carelessness, and considerably easier to act on, because it asks nothing of anybody’s judgement in 2019. It only asks whether the constraint still holds. A cost becomes waste when the alternative changes. The old decision does not become irrational in retrospect; the environment moves around it. Which is also why both taxes have grown rather than shrunk — a decision that was correct when taken is rarely reopened, and rising costs inside it are read as inflation rather than as evidence.

6 

How the two taxes feed each other

Each tax is self-reinforcing on its own. Weaker owned attention deepens dependence on platforms, which leaves less reason to invest in the owned channel, which weakens the attention further. More applications create more integration and more reconciliation, which consumes the capacity that might have gone into consolidating them.

The more interesting relationship is the one between them, and it is the reason these belong in one argument rather than two.

Figure 4. The connection runs in both directions, and the second direction is the one that keeps the loop closed.

Read clockwise from the top left. Foundations built separately in each system mean there is no single record of the customer. Without a single record, targeting on owned channels is weak — the business knows what somebody bought in one system and what they browsed in another and cannot reliably join the two. Weak targeting on owned channels is precisely why reach gets rented from platforms which, having observed the same person across thousands of contexts, know more about them than the brand whose product they bought.

That much is familiar. The step that closes the loop is the one at the bottom left, and it is worth sitting with. A company with a large reacquisition budget has, in effect, purchased a way of not fixing its foundations. Reach can be bought. Attention can be bought. So the incomplete customer record never becomes urgent, the consolidation project never reaches the top of the list, and the money that would have paid for it is already committed to the auction.

Stated as an accounting relationship rather than a diagram: the Reacquisition Tax subsidises the App-Stack Tax, and the App-Stack Tax manufactures more Reacquisition Tax. The business pays platforms because its software cannot assemble the customer truth it already possesses, and postpones fixing the software because platforms can always be paid to find the customer again.

They are not two parallel problems that happen to appear in the same business. They are one problem arriving as two invoices.

Key points

—  A cost becomes waste when the alternative changes. The environment moves around the old decision.

—  Fragmented foundations produce an incomplete record, which is why owned targeting is weak.

—  A budget large enough to buy reach removes the urgency to earn it — and that closes the loop.

—  One problem, two invoices.

Part III: Three Cuts

7  One loop does not need two programmes

The diagnosis carries an implication that is easy to miss and worth stating on its own. If the two taxes form a single loop, they do not require two transformation programmes. A loop weakens wherever it is broken. So the question facing a business is not how do we fix all of this but which single cut can we make.

One precision, because the loop invites an overstatement worth avoiding. The three cuts do not each solve both taxes. They act at different points and do different work. Measurement drains neither tax; it manufactures the pressure the loop removed. Rebuilding owned attention reduces the Reacquisition Tax directly, and withdraws the subsidy that lets an unfixed stack stay unfixed. Consolidating the foundations reduces the App-Stack Tax directly, and improves the conditions under which owned growth is possible at all. Each cut weakens the loop; none of them is a substitute for the others.

Figure 5. Three places the loop can be broken. Each acts at a different point, and they differ in cost, speed and who has to agree.

The cut	What it reduces	What it costs	When it pays
1  Measure it	Neither tax directly. It produces the number that gives the waste an owner and restores the pressure the loop removed.	A fortnight of somebody’s time. No system changes. No budget.	Immediately, as pressure — which is the missing ingredient.
2  Rebuild owned attention	The Reacquisition Tax directly, and it withdraws the subsidy protecting the unfixed stack.	Modest, and payable out of the tax it reduces.	One to two quarters, measurable against a control.
3  Consolidate the foundations	The App-Stack Tax directly, and it improves the conditions for owned growth.	Migration effort, now an order of magnitude below what it was.	Slowest and most durable. Compounds thereafter.

Table 2. The three cuts, in the order most businesses can take them.

The rest of this essay takes them in turn. The first requires nothing from any supplier, which is deliberate: a diagnosis that can only be acted on by buying something is a diagnosis nobody should trust.

8 

Cut one: measure it

Both taxes can be sized approximately in an afternoon, and the reason this is so rarely done is not difficulty.

The question	How to answer it	What a bad answer looks like
What share of paid conversions were already known to the business?	Take a recent period of paid conversions and match the identities against the customer file as it stood before the paid interaction. Separate people new to the business from previous buyers, subscribers, app users and known prospects.	Nobody has run the match. In most companies the figure is not disputed — it has never been produced.
Of those, how many had received a useful owned message in the weeks before?	Not another promotion — a message informed by that person’s state, context and prior relationship. This separates paid recovery that was unavoidable from attention that was allowed to decay.	The last owned contact was a discount sent to the whole list, and it went out after the paid conversion.
How many systems hold their own version of the customer, the product and the transaction?	Count every system that stores or reconstructs identity, catalogue, orders, consent, events or workflow state — including applications that merely keep a local copy. Then count the integrations built to keep them agreeing.	The number of integrations exceeds the number of systems, and somebody’s job title exists because of it.

Table 3. Three questions, all answerable from data the business already holds.

None of this will produce an audited number. Identity matching misses some people and overstates others; attribution windows complicate the story. That is acceptable, because the first objective is not precision. It is to find out whether the machine reporting new customers contains a material known-customer component, and whether the business has bought eight applications or eight incomplete versions of itself.

This cut looks like the weakest of the three and is usually the most important, for a reason that comes straight out of the loop. The loop closes at no pressure to fix the foundations. Measurement is the only cut that manufactures the missing pressure — and it is almost never chosen, because nobody is promoted for producing a number that makes their own budget look wasteful. Somebody senior has to ask for it, be willing to receive an uncomfortable answer, and then act on it against the budgets it implicates. Visibility creates pressure. It does not by itself defeat the people who benefit from the arrangement being invisible.

9 

Cut two: rebuild owned attention

The second cut attacks the point where weak owned targeting hands the customer to a platform. If the owned channel earns a response again, recovery stops requiring an auction — and the reacquisition budget stops subsidising the unfixed stack.

Three things have to change, and they are true whoever supplies them. Email is the natural place to start, being the one channel a business owns outright and the one it has most thoroughly worn out.

First, the message has to be current when it is read rather than when it was sent, assembled from the state of the customer and the catalogue at the moment of opening. An email written on Tuesday and read on Friday is presently a Tuesday email; it does not have to be. Second, the useful action has to be completable inside the message rather than three redirects away from it, because that is where most intent is lost. Third — and most brands have none of this at all — some proportion of contact has to exist to maintain the relationship rather than to sell. A channel used only for selling teaches people not to open it, and that lesson, once learnt, is what the reacquisition budget is later paying to unlearn.

Then accountability, which matters more than any supplier’s method. Whoever does this work should be answerable for a customer state rather than for a volume of campaigns, and the effect should be established against a randomised control group, running concurrently, receiving the brand’s pre-agreed baseline treatment — the existing programme, not nothing at all. A control that receives nothing inflates the apparent result and deserves the resistance it will get from anybody asked to deprive their own customers to prove a supplier’s point. The comparison that means anything is against what the business would otherwise have done.

Most businesses will do this work themselves, on a platform they already own, and carry the result themselves. That is the ordinary case and it remains the right one. A transfer of accountability is for the pools a company’s own operation has not closed, and there are usually two of them: customers who are still engaged but whose valuable action has stalled, and customers who have gone dark and are being re-bought through paid channels. The first is larger than most people expect and resolves in weeks; the second is the one visible in the media budget.

What we have built for this

The doctrine is NeoMarketing, and its first commercial forms are Progency Finish and Progency Recover — a managed mandate over one of those declared pools, with accountability for the state of those customers rather than for the campaigns sent to them.

The commercial arrangement is deliberately awkward for us. A baseline is agreed before anything starts, a randomised control runs alongside on that baseline, and payment is a share of the verified difference. No lift, no payment. A supplier arguing that a brand pays too much to re-buy its own customers should be willing to be paid only when it demonstrably reduces that bill. Otherwise the argument is a different invoice with better rhetoric.

What this does not do:

• It does not replace paid acquisition. It makes paid the fallback rather than the first reflex.
• It does not recover everybody. Some customers have left, and the control group is how you find out which.
• It does not work without that control. A claim of lift with no comparison is a claim about the weather.
• It does not fix the foundations. It buys the time that fixing them requires.

10 

Cut three: consolidate the foundations

The third cut attacks the origin of the loop: the same substructure, funded once per supplier. The generic move is to stop paying for foundations by the vendor and start paying for them once — one customer record, one catalogue, one order history, one consent ledger, one workflow engine — with the distinctive part of each application sitting on top of that rather than beside it.

The renewal test from section three is how this becomes actionable without a transformation programme. Applications that contribute distinctive capability stay. Applications whose cost is mostly a private rebuild of shared foundations are candidates for consolidation, and there are usually more of them than anybody expects.

The prize is not a smaller software bill, though that follows. It is the removal of hand-offs that exist only because separate applications were built. Search intent should change the next email. A support issue should suppress a promotion. A declared preference should alter merchandising the same afternoon. A well-integrated stack can be made to do some of this, with friction, delay and a standing maintenance cost; on shared foundations it is not a project at all, because the hand-off has stopped existing.

What we have built for this

The Software Foundry builds products on one shared core. The first covers eight jobs: import customers, consent and suppression; ingest catalogue, orders and events; capture identities through forms and pop-ups; build useful segments; send campaigns reliably; run the six essential lifecycle flows; report revenue and activity simply; and migrate from the incumbent without risk. The promise is four items long — one bill, eight jobs, a tenth of the price, a safe way out — and the price is published, the same page shown to everyone, with usage metered and nothing negotiated.

Roughly a tenth of the incumbent price is possible because producing software is no longer the expensive part, and because the foundations are built once rather than once per product. It is not a discount and not a promotional tier that later rises. It is a thesis we intend to prove rather than a result we are claiming, and the proof is whether the second product reuses enough of the first.

What this does not do:

• It does not replace the commerce platform. It sits alongside it.
• It does not do reviews, loyalty, helpdesk or subscriptions, and it has no journey canvas.
• It does not do custom work. Standardisation is what the price is made of.
• It is not outcome-priced. Its accountability is that leaving is as easy as arriving.

11  Why the two remedies are one thesis

The two remedies price themselves in opposite directions, and the contrast is not an inconsistency. It is the clearest evidence that both follow from the same shift.

Figure 6. The same shift, read from both ends.

Artificial intelligence is collapsing the cost of producing capability. It is not collapsing the cost of trust, of migration, of judgement, or of accountability for whether a thing worked. The abundant half is getting cheaper and the scarce half is not. When everybody can produce the capability, the position worth holding is being the party willing to be measured on the result.

So software can become dramatically cheaper in the same period that a verified outcome becomes more valuable. One remedy charges a published price that does not move with the customer’s success, because production became cheap. The other charges a share of a verified difference, because accountability did not. A business can take either cut first — or take only the first cut, buy nothing, and still be better off than it was.

What it should not do is keep paying both taxes on the grounds that each individual invoice looks reasonable. They are one problem arriving as two invoices, and the loop closes at the point where the money that would have fixed it has already been committed to the auction. The opportunity is not to automate the existing bills, or to negotiate them down by a further eight per cent. It is to stop paying them for value the business already created — a customer relationship it built once, and foundations it has now funded several times over.

Key points

—  One loop, three cuts. Each acts at a different point; none substitutes for the others.

—  Measurement is the cut that manufactures the pressure the loop removed, and it requires no supplier.

—  Attention work buys the time that fixing the foundations needs; it does not substitute for it.

—  One price rises with verified success; the other refuses to rise. Both follow from the same shift.

Assets should compound, not be repurchased.

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.