Rajesh Jain

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.

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.

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.

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.

Why generating software is becoming easy and keeping its promise is not

The previous essay, Software After Code, argued that machine generation removes code from the centre of what humans make — and raised an objection it deliberately left open. If producing software has become cheap for vendors, it has become cheap for customers too. Many companies will build what they used to buy, and some of them should.

This essay takes up what happens after that decision — not to argue anyone out of it, but because the part that has become cheap and the part that has not are rarely told apart until somebody is living with the difference.

The claim of this essay: generation produces visible capability. Everything that makes capability dependable sits underneath it, is unaffected by the collapse in production cost, and has become more expensive rather than less — because software now acts.

1

The Application Built in a Weekend

A logistics company with about forty people has a problem that every operations manager will recognise. Delivery exceptions — the failed drop, the refused consignment, the address that does not exist — arrive through three channels and are tracked in a spreadsheet that four people edit and nobody trusts. The commercial software that would handle this properly costs more than the problem appears to be worth, and the last evaluation stalled on a six-week implementation nobody had time for.

So the operations lead, who is technically capable but not a software engineer, spends a Saturday with a coding agent. By Sunday evening there is a working application: exceptions pull in from all three sources, get classified, route to the right person, escalate on a timer, and produce a weekly summary that is more useful than anything the spreadsheet ever gave anyone. It cost a weekend and the price of some inference. On Monday the team starts using it, and within a fortnight nobody would go back.

This story should be granted completely, because it is real and it is going to become ordinary. The application is good. It fits the business better than a purchased product would have, because it was shaped by somebody who understood the work. It cost a rounding error. Any argument that begins by suggesting this could not have happened, or that the result must secretly be bad, is not an argument — it is a vendor protecting a position, and the reader will smell it immediately.

Now move forward twelve months, and watch what the year does.

In month three, one of the three source systems changes its authentication, on its own schedule, with an email nobody read. Exceptions from that channel stop arriving. Because they stop arriving rather than arriving wrongly, nothing looks broken — the queue simply gets shorter, which everybody enjoys for eleven days.

In month five, a customer disputes a charge arising from an automated escalation, and asks the company to show why the system did what it did. There is no record beyond the current state of the database. The reasoning existed at the moment it ran and was never written down.

In month seven, somebody patches the classification rule directly, at eleven at night, to stop a client complaint. It works. It is never reconciled with anything, and nobody is quite sure afterwards whether that patch is still in effect.

In month nine, the operations lead who built it takes a job elsewhere. The application keeps running. Nobody who remains can say with confidence why the timer is set to forty-eight hours, which exception types were deliberately excluded, or which of the several near-identical rules is the one that fires in practice.

In month eleven, an auditor asks a straightforward question about retention of customer data, and the honest answer takes three weeks to assemble.

None of this is a story about a bad application. It is a story about the difference between a thing that works and a thing that can be relied upon — and that difference did not become cheaper when generation did.

The repository took a weekend. The promise began on Monday morning.

Day two	Month twelve
A working application	A connector has changed, silently
Ordinary cases automated	Exceptions have accumulated
A visible workflow replaces a spreadsheet	One manual patch is unreconciled
The builder knows every decision	The builder has left
The demonstration succeeds	Somebody has to keep the promise

Table 1. The same application, twelve months apart. Nothing in the right-hand column is a defect in the left.

Key points

• The weekend build is real, is often better-fitted than a purchased product, and is going to become ordinary.
• What arrives in the year afterwards is not a defect in the application. It is the obligation that was never priced.
• The repository took a weekend. The promise began on Monday morning.

2

The Demo and the Promise

Software has always divided into two parts, and the division was always uncomfortable to talk about because the second part is invisible in every demonstration and consumes most of the effort.

The first part is what the software does when things go as expected. Screens and forms. The ordinary workflow. Reading and writing records. Dashboards. Standard integrations with well-behaved systems. Conventional business logic. This part is now substantially generatable, and getting more so. It is also the entire content of every demonstration, every screenshot and every evaluation — which is why buyers have always over-weighted it, and why the software industry learned to sell to it.

The second part is what the software does when things do not go as expected. The edge case nobody thought of at design time. The exception that is legitimate but looks fraudulent. The operating history that explains why this rule exists. Provenance — who set this, when, on whose authority. Permissions. Consent, and evidence of consent. The connector that changes on somebody else’s schedule. Security. Monitoring that notices absence, not just failure. The ability to reverse an action. Compliance evidence produced on demand. Continuity when the person who understood it leaves. And, underneath all of it, somebody answerable when the software gets it wrong.

Figure 1. Generation reaches the part above the line. The part below it is what a demonstration cannot show.

There is a structural reason the second part gets under-bought, and it is worth naming because it explains a great deal of behaviour on both sides of the transaction. Dependability is largely built from capabilities whose success appears as the absence of an event. Nobody celebrates a suppression rule that correctly stopped a prohibited message; the message simply never arrives, and no one knows it nearly did. A clean audit trail goes unnoticed until the complaint, the dispute or the investigation. A reversal mechanism is unused on almost every day it exists and indispensable on the one day it is needed. Software that displays a feature accrues credit continuously. Software that prevents a disaster accrues none, until the disaster.

A product is not defined by what it does when everything is normal. It is defined by what it does when reality departs from the demonstration.

A demonstration proves that software can work. This second part determines whether it can be trusted.

The split is not new. What is new is the ratio, and it moved twice.

It moved once because generation collapsed the cost of the first part and left the second part exactly where it was. A visible capability that used to take a team three months now takes a weekend; the obligation underneath it takes the same year it always took. Anything that becomes cheap while its complement does not has raised the relative price of the complement — which is the whole economic content of this essay, and it applies to the vendor exactly as much as to the customer.

And it moved a second time, for a reason that has nothing to do with production cost. Software has started to act.

The previous essay set out the ladder along which authority is granted — from observing, through recommending and preparing, to executing, operating and eventually owning a goal. What matters here is only the consequence at the bottom of the ladder. When software displayed information and waited, a missing edge case produced a wrong screen. Somebody looked at it, frowned, and nothing had happened in the world. When software acts, the identical gap produces an action: the message sent to somebody who withdrew consent, the refund issued that should have been reviewed, the escalation triggered against a customer who did nothing wrong, the record altered in a system that other systems believe.

Figure 2. The same specification gap, before and after delegation.

A deterministic system fails visibly and locally. A system with authority and a weak specification fails confidently and at scale — and it fails silently, because there is no screen for anybody to frown at. It is found by its consequences, which arrive later, through a customer, a regulator or an auditor.

So the expensive part is not a legacy concern that better generation will eventually reach. Delegation is what made it expensive. The more capable the software becomes, the more the value sits in the part that generation does not touch.

Key points

• The first part is what software does when things go as expected. It is now substantially generatable, and it is the whole of every demonstration.
• The second part is what it does when they do not. It did not become cheaper.
• Dependability is built from capabilities whose success appears as the absence of an event — which is why it is systematically under-bought.
• Anything that becomes cheap while its complement does not has raised the relative price of the complement.
• Delegation moved the ratio a second time: the same gap that once produced a wrong screen now produces an action.

3

What the Customer’s Agent Cannot Finish

There is a comfortable version of this argument that should be refused, because it is wrong and it will not survive a serious reader.

The comfortable version says that models lack domain knowledge — that a coding agent does not understand logistics, or lending, or clinical operations, and that this is what a specialist vendor sells. That claim is already shaky and gets weaker every year. Models know a great deal about how a returns process, a credit assessment, a reconciliation or a triage protocol normally works. They will know more next year. Any thesis that depends on models staying ignorant is a thesis with an expiry date.

The sharper claim survives:

Generic domain knowledge is becoming abundant. Current, organisation-specific operating truth is not.

Consider what an agent generating that exceptions application would have needed to know, none of which is generic. Which classification does this company use, and how does it differ from the industry norm, and why — because it does differ, and the reason is usually an incident that happened once. Which of these rules is a legal requirement and which is a preference that somebody could change if asked? Where did the forty-eight hour timer come from: a contract, a regulation, or a decision made in a meeting in 2021 by somebody who has left? Which exceptions have been deliberately accepted, by whom, and on what grounds? Who is permitted to override, and what happens when two rules apply and disagree? What evidence would demonstrate, to somebody hostile, that the policy was followed? And — the question that quietly governs all the others — is any of this still true?

None of that is in a model, and none of it is in the request the operations lead typed on a Saturday. It exists in fragments. Some sits in policy documents nobody has read since they were written. Some sits in the configuration of an existing system, where it was recorded as a setting rather than a decision. Some lives in spreadsheets, email threads and support macros. And a great deal survives only in the memory of five or six experienced people who know which written rule is not the whole rule. Turning those fragments into an executable account of how the business operates is not clerical work. It is organisational design — and it is difficult in a way that has nothing to do with software.

It also involves a set of distinctions that only an organisation can draw. Policy has to be separated from habit. The current rule has to be separated from the historical workaround that outlived its cause. Authority has to be separated from convenience. And stated intention has to be separated from what the business is prepared to enforce when enforcing it costs something. Without those separations, generated software will reproduce an organisation’s folklore as confidently as its policy, and with the same authority to act on it.

Which sharpens what the customer’s own agent can and cannot do, and the concession matters. It can do more of this than is comfortable to admit. It can interview, read the existing configuration, draft a specification, and — valuably — identify contradictions that nobody had noticed, because it does not share the assumptions that made them invisible. What it cannot do is decide which of two contested truths the organisation should adopt, or determine who is entitled to accept the risk of getting that wrong. That is not a knowledge problem. It is an institutional act, and it requires somebody with standing to perform it and to be answerable afterwards.

This is why the weekend application is so often excellent and so rarely complete. It captures the operating reality as one well-informed person understood it on one day. That is a valuable artefact. It is not the same as an account of how the business works that stays accurate as the business changes — and the gap between those two things is invisible on Monday and expensive in month nine.

Two properties make organisational truth hard to hold, and both are worth naming precisely because neither is a technical problem.

The first is provenance. A rule without a source cannot be safely changed. Anyone who has worked in an established business has met the constraint nobody can explain and nobody dares remove, and the reason the fear is rational is that the rule might be load-bearing. When rules are captured only as behaviour — in code, or in a generated implementation — provenance is exactly what is lost. The system knows what to do and not why, which is fine until the day somebody needs to change it.

The second is currency. Operating truth decays. A jurisdiction adds a requirement. A contract is renegotiated. A category behaves differently after a bad quarter and the rule that was written for the old behaviour quietly stops fitting. Nothing about generation addresses this. A system generated from a perfect specification in January is running on a January account of the world in November, unless somebody has been maintaining it — which is a job, and it is the job that most self-build arrangements have not assigned to anyone.

So the scarce input in software is not code, and it is not domain knowledge in the abstract. It is a current, sourced, tested account of how one particular organisation operates — held by somebody whose job is to keep it true.

Key points

• Refuse the comfortable claim that models lack domain knowledge. It is weak and it expires.
• Generic domain knowledge is becoming abundant. Current, organisation-specific operating truth is not.
• Turning fragments into an executable account of how a business operates is not clerical work. It is organisational design.
• Without separating policy from habit, generated software reproduces an organisation’s folklore as confidently as its policy.
• The agent can draft the specification and find the contradictions. Deciding which contested truth to adopt is an institutional act.
• Provenance and currency are the two properties that make organisational truth hard to hold — and neither is a technical problem.

4

The Maintenance Obligation

The previous essay described the machinery that reduces this burden — change a shared truth once, and every capability that depends on it is rebuilt and revalidated. That machinery is real, and it is the strongest argument a producer has. It also has to be built, staffed and run by somebody, which is the point of this section.

Here is the obligation, stated plainly, because it is usually discussed as an abstraction and it is not an abstraction — it is a set of jobs that appear on somebody’s calendar.

Connectors. Every integration is a dependency on a third party’s roadmap. Interfaces change, deprecate, tighten their authentication, alter their rate limits and occasionally disappear. The work arrives unscheduled, in a quarter that had other plans, and the failure mode that matters is not the loud one. A connector that breaks noisily gets fixed on the day. A connector that silently stops delivering a subset of records is discovered weeks later, and the interval between those two events is where the real damage sits.

Releases. Something has to establish that the current version still does what the last version did. In a generated system this is more important rather than less, because the implementation may have been rebuilt entirely between one week and the next.

Incidents. Somebody answers when it fails, and the answer is required at inconvenient hours by definition. This is the single most under-costed item in every self-build decision, because it is not a task but an availability commitment — which is a very different thing to ask of a person who already has a job.

Security. Vulnerabilities are disclosed on a schedule set by researchers, not by the business. Somebody must be watching, must know which disclosure applies, and must be able to act quickly.

Regulation. Rules change in one market and have to be threaded through a system built for the world as it was. Somebody must notice, interpret, and know which behaviour is affected.

Permissions. People join, change roles and leave. Access granted in a hurry is rarely reviewed, and permission drift is the quiet precondition of most serious incidents.

Support. Somebody answers the colleague who cannot make it work. At small scale this is invisible; it is also how most internal tools die in practice — not through failure, but through nobody being available to explain them until people stop bothering.

Continuity. The knowledge has to survive the person. This is the obligation that self-build arrangements fail most reliably, because it is the only one that produces no symptom at all until the day it produces every symptom at once.

Obligation inherited	What happens if it is neglected
Specification maintenance	The system enforces yesterday’s truth, confidently
Connector monitoring	Silent breakage, discovered by its consequences
Permissions	Actions occur without valid authority behind them
Release testing	A local fix quietly breaks a path nobody was watching
Incident response	The same harm repeats, because the cause was never found
Regulatory tracking	The implementation becomes non-compliant without changing
Security	A useful tool becomes an exposure
Support and continuity	The tool becomes an orphan and is quietly abandoned
Accountability	Responsibility is discovered to be nobody’s, after the event

Table 2. Self-building removes an invoice. It does not remove this column.

Figure 3. The two costs are not the same shape, which is why comparing them once is misleading.

That shape is the argument. The cost of creation is a point. The cost of the promise is a line — and the line runs for as long as anybody depends on the software. A comparison made at the moment of creation is not comparing like with like, which is why the weekend build looks so overwhelmingly favourable in the week it is made and merely reasonable three years later.

Now the honest boundary, because this section could easily be read as an argument that self-building is a mistake, and it is not one.

A large company with real engineering depth is already carrying every item on that list for other reasons. It has an on-call rota, a security function, a release process, an access review, a compliance team. For that company the marginal cost of adding one more internally built system is small, and the fit advantage is large. Such a company should probably build more than it does.

The forty-person logistics business is being offered something different. It is being offered the chance to become, in a small way, a software operation — and most companies do not want to be one, in the same way that most companies do not run their own payroll engine or their own payment infrastructure, though both are technically within reach and neither is conceptually hard. The question is not whether the obligation can be carried. It is whether carrying it is what this company wants to spend itself on.

Key points

• The obligation is not an abstraction. It is connectors, releases, incidents, security, regulation, permissions, support and continuity.
• The cost of creation is a point. The cost of the promise is a line.
• A company already carrying that list for other reasons should probably build more than it does.
• For everyone else the question is not whether the obligation can be carried, but whether carrying it is what the company wants to spend itself on.

5

Accountability for the Act

Everything so far has been about effort — work that must be done by somebody, priced or unpriced. The deepest layer is not about effort at all. It is about things that cannot be produced on demand at any price, because they are accumulated rather than made.

Standing with third parties. A great deal of consequential software depends on how other systems and institutions regard the sender. Whether messages are delivered or filtered. Whether an interface grants elevated limits. Whether a payment processor treats the traffic as ordinary or as risk. Whether a platform certifies the integration. None of that can be generated. It is built over years through consistent behaviour, and it can be destroyed in an afternoon by a system acting confidently on a bad rule. A new application starts with none of it, and that starting position is invisible until the first thing goes wrong.

Consent with provenance. Not a flag in a database recording that permission exists, but a record of how it was obtained, when, under which wording, in which jurisdiction, and what the person was told at the time — durable enough to be produced in a dispute months later, by which point the interface that captured it may not exist in that form. This is straightforward to build in principle. It is almost never built by somebody assembling an application in a weekend, because it is invisible unless somebody asks, and nobody asks until it matters.

Suppression that must never fail. Every system that acts on people needs a set of rules that hold under all circumstances: this person must not be contacted, this account must not be charged, this record must not be exported. What makes these hard is not the logic — the logic is trivial. It is that they must survive regeneration, refactoring, a new developer, a migration and an urgent change made under pressure. This is the clearest case in software where being right on average is worth nothing: there is no persuasive account of a suppression failure that begins with the system having been intelligent most of the time. A rule that holds most of the time is not a suppression rule. It is a preference.

A record that reconstructs the decision. Not logs of what happened, which most systems have, but an account of why: what the system knew, which policy was in force, who set it, what boundary applied, what it did, and what state it left behind. This is the difference between being able to say the system sent the message and being able to say why the system was entitled to send it. A regulator, a court and a serious customer all ask the second question. Intelligence without a reconstructable record is not autonomy. It is opacity — and no organisation should grant authority to something it cannot afterwards examine.

Reversal. The ability to undo an action, including its consequences in other systems that have already acted on it. Reversal is not the inverse operation, and the hardest version is not the clean failure but the partial one: the refund that stops halfway, leaving the order system and the payment system holding different accounts of reality. Nothing has failed loudly; the two systems simply disagree, and each will go on acting on its own version. Reversal is a designed capability, and it has to be designed before it is needed — which means before anybody has evidence that it will be. Where an action cannot be reversed, the authority threshold in front of it should be higher, which is a design rule and rarely treated as one.

A named party who is answerable. When software acts wrongly and somebody is harmed, the question is not only what failed. It is who is responsible. In a purchased arrangement the answer is written down, sits with an organisation that carries insurance and has something to lose, and is enforceable. In a self-built arrangement the answer is the company itself — which may be perfectly acceptable, and is a materially different position that ought to be entered deliberately rather than discovered afterwards.

These items share a property that separates them from everything in the previous section. Effort can be bought late. Standing, provenance and reversibility cannot. A company that decides in month twelve to take its obligations seriously can hire, staff a rota and write the runbooks. It cannot retroactively acquire three years of good conduct with a mail provider, or produce a consent record for a permission captured by an interface that no longer exists, or reverse an action through a design that was never built.

Which is why this layer, rather than the maintenance layer, is where the deflation stops. AI makes software creation cheaper. It makes trusted action more consequential — and the second effect is larger than the first for any system permitted to do anything that matters.

Key points

• This layer is accumulated rather than made: standing with third parties, consent provenance, suppression, decision records, reversal, and a named answerable party.
• A rule that holds most of the time is not a suppression rule. It is a preference.
• Effort can be bought late. Standing, provenance and reversibility cannot.
• AI makes software creation cheaper. It makes trusted action more consequential.

6

Why the Vendor Still Exists

Return to the objection that opened this essay, now that both sides of it are visible.

The forty-person logistics company was never choosing between having software and not having it. It was choosing where the obligation would sit. Self-building does not remove the software producer from the arrangement. It relocates the producer inside the customer, and the relocation is invisible on the weekend it happens because the obligation has not started yet.

Stated that way, the decision becomes a reasonable one to make rather than a trap. Some companies will look at the obligation, recognise that they are already carrying most of it, and build — correctly. Others will look at the same list and conclude that they would rather buy the promise than become the party who keeps it. Between those positions sits a range that will grow: managed specifications, shared runtimes, certified components, arrangements where the customer holds its distinctive rules and a producer maintains the machinery underneath. The decline of code scarcity produces more ways to source software, not one right answer — and the useful question in every one of them is the same. Who is carrying the obligation, and do they know they are carrying it?

For the producer, this changes what a software company is selling, and the change is not cosmetic. It can no longer sell access to a capability, because capability is becoming abundant. What remains sellable is everything this essay has described: an account of the customer’s operating truth that somebody keeps current; the machinery that carries a change safely across everything depending on it; the migration that makes arriving and leaving survivable; the accumulated standing that lets the software be trusted by third parties; and a named party who is answerable when it acts.

That is a harder business than selling software was. It is also a more defensible one, because none of it can be generated on a Saturday.

One misreading has to be closed off before it takes hold, because this argument can be turned into something it is not. Nothing here is a defence of expensive software. A great deal of what the industry charges for deserves to collapse: features nobody uses, foundations rebuilt for every product, integrations assembled by hand, implementation projects that exist because the product could not be adopted without them, and the organisational overhead layered on top of all of it. The obligation described in these six sections is not what made traditional software expensive. It was one line item among several, and often not the largest.

So the correct conclusion is narrow and it should be stated precisely. The waste should be removed. The promise should not. Affordability that is achieved by deleting the obligation is not affordability — it is unpriced risk sitting quietly on the buyer’s side of the arrangement, and it will be discovered eventually, usually by somebody who did not know they had bought it. The obligation has to be industrialised instead: shared foundations, reusable tests, monitoring that runs without being staffed, deterministic execution for repeated work, and regeneration when the governing truth changes. That is the difference between software that is cheap and software that is affordable, and the distinction becomes more important as the price falls, not less.

Which suggests something a producer can do rather than merely claim. Make the obligation inspectable. Show which specifications are current and when each was last reviewed. Show which dependencies are being watched. Show what authority the system currently holds and who granted it. Show how a decision can be reconstructed, and how quickly an action can be reversed. Every one of those is checkable, and none of them appears on a feature list. Trust moves from a brand promise to inspectable operating evidence — and at a low price that shift is not optional, because a low price is exactly what a buyer would expect an unpriced risk to look like.

The competitive question is no longer who can build the capability. It is who can keep it correct, current, connected and accountable as the world changes.

And the answer to the objection can now be put in a single line. The customer is not being asked to pay for software; the customer can produce software. The customer is being offered the chance not to become the party who is responsible for it — which is worth something, and worth more every time the software is permitted to act on its own.

The future software company will not win because it writes more code. It will win because customers trust it with more authority.