The Vertical Test (Software Foundry Series #9)

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 by

Rajesh Jain

An Entrepreneur based in Mumbai, India.