Claims Management is live. Automate freight claims from detection to dispute resolution.

Claims Management is live.

Explore it here

.

.

.

Share:

Why locking customers into one system was the standard playbook, and why the cost structure that made it rational is gone.

For twenty years, the correct strategy in B2B software was obvious enough that it stopped being discussed. Pick a vertical. Build the definitive system of record for it. Get enough customers that your product becomes the shape of the industry rather than a tool used by it. Expand sideways into adjacent workflows until leaving you means rebuilding the business. Vertical monopoly, defensible, high multiple, everyone happy.

That strategy was not a matter of taste. It was arithmetic.

Why was vertical monopoly the default B2B software strategy?

Software used to be expensive to produce and nearly free to copy. That single asymmetry generated the entire playbook.

If it costs $4M to build a warehouse management system, you cannot sell it to eleven companies. You need four hundred. And to get four hundred companies onto one codebase, you have to find the intersection of what all four hundred need, build that, and then spend the next decade telling the ones who don’t fit that their process is wrong.

This is why enterprise software feels the way it feels. The generality is not a feature, it’s amortization. Configuration screens, custom field builders, rules engines, the entire integration marketplace; all of it exists to push the last mile of specificity onto the customer, because the vendor cannot afford to walk it for them. You buy a platform and then you hire two people and buy a Zapier seat to make the platform describe your actual operation. The gap between the software and the business is filled with labor, and it is your labor.

Under that cost structure, having already built the thing is a real moat, and monopolizing the vertical is the rational way to defend a large sunk cost. My own industry has been running the playbook in public for a decade. When Körber took KKR money in 2021, its own executive explained the logic plainly: M&A was the fastest way to broaden the suite into what customers were asking for; HighJump and MercuryGate followed. Blue Yonder bought One Network to turn planning software into a multi-enterprise network. Manhattan pulled warehouse, transportation, order, and labor management onto a single platform and made the platform itself the pitch. As of this month, consolidation into one unified layer is still the stated ambition across the category. It wasn’t a side effect. It was the goal.

What changed the economics of building B2B software?

Two things, and the second one gets less attention than it deserves.

The cost of producing software fell. Not to zero, but far enough that it no longer dominates the equation; when the dominant term in an equation stops dominating, the strategy that fell out of it stops being optimal. McKinsey’s developer-productivity lab work found coding tasks completed up to twice as fast with generative AI. Their own data carries a crucial caveat: time savings fell below 10% on tasks developers rated highly complex. Menlo Ventures put coding at $4B in 2025, 55% of departmental AI spend and the largest single application category in the enterprise. Retool’s 2026 build-versus-buy survey of 817 builders found 35% had already replaced at least one SaaS tool with a custom build, and 78% expected to build more of their own tools this year.

Practitioner estimates (worth treating as scope rather than gospel, since they come from firms with a commercial interest in the answer) now put a mid-complexity internal tool at two to three months and $20K to $40K, against four to six months and $50K to $80K under the old assumptions.

The important part isn’t that engineers ship faster. It’s that the minimum viable size of a market collapsed. When a working solution costs six weeks instead of two years, a market of forty companies is a business. A market of one company is a project you can take at a real margin. Every niche previously dismissed for insufficient TAM is now addressable, and there are far more niches than there were ever verticals.

They are also fluid. Niches form and dissolve faster than a roadmap cycle. Cold-chain 3PLs handling pharma returns under a specific state rule is a real market with real budget, and it may not exist in that shape in three years. Under the old arithmetic you couldn’t serve it; by the time you’d built for it, it would be gone. Now you can be in and out of it profitably. The capacity to reconfigure is worth more than the capacity to plan.

The unit of value moved from seats to work. a16z called this in late 2024: software is becoming labor, and per-seat is no longer the atomic unit of software. The market is visibly moving. ICONIQ’s January 2026 snapshot of roughly 300 software executives found 58% still carrying a subscription or platform component, but consumption-based pricing at 35% and outcome-based at 18%, both up meaningfully in six months.

This matters more than the pricing-page mechanics suggest. When you sell access, your addressable market is a software budget, and software budgets are standardized across an industry. When you sell work, your addressable market is a labor budget; labor budgets are local, idiosyncratic, and specific to the building they’re spent in.

Both changes point the same direction. The largest common denominator stops being where the money is. a16z’s David Haber frames it as market structure being the new TAM: where the system of record in a vertical is fragmented, the opening is to do the work surrounding those systems and back into the center later. Their own market commentary this summer was blunter: software alone is not a moat, and years of accumulated ARR and enormous feature sets are yesterday’s news.

If code is cheap, what’s the new competitive moat?

If code is cheap, having written a lot of code is not a moat. This is the part that stings, because engineering throughput was the thing a lot of us were good at and the thing our org charts are shaped around.

What’s actually scarce now:

° Knowing what to build. Not in the abstract; knowing that the pickers ignore the scanner on the second shift, and why, and what would happen if you fixed it.

° Physical and organizational access. Being allowed on the floor. Being trusted with the data. Having the relationship with the ops director who decides whether the thing gets used.

° Being answerable for the outcome. Not shipping a capability, but owning the number that moves.

None of these compress the way code compresses. They’re all bought with time, presence, and trust, which is to say they’re bought at pre-AI prices while your production costs fall. That spread is the whole opportunity.

What customers want out of this is usually not sophisticated. It’s bespoke but boring: this data, from there, transformed that way, in front of that person, by Tuesday. The work is specific, not complex. The old model couldn’t afford specific, so it sold configurable and hoped.

And this is where the “so everyone will just build it themselves” version of the argument overshoots. The same Menlo data that shows coding spend exploding also shows enterprises buying 76% of their AI use cases rather than building them, up from 53% the year before. Stax’s read from this spring explains why: AI lowers the cost to build software and raises the cost to own it. Maintenance, model behavior, regulatory change, and auditability compound over time, and a vendor amortizes that across thousands of sites where a single operator cannot. The integration tax is real too; Deposco has documented “standard” warehouse integrations carrying enough hidden backend work to stretch deployments 40 to 60% past estimate, and a 3PL that ended up running its own integration layer because its customers couldn’t change anything on their side.

So the buyer’s actual position is narrower than either side of the build-versus-buy debate admits. I don’t want to build it. I don’t want your monolith. I want something that bends to my building without a six-month IT project, and I want to be able to leave.

Why is consulting no longer a low-margin business model?

For two decades, services revenue was the thing you apologized for on a board call. Linear scaling, headcount-bound margins, no multiple. The orthodoxy said productize or die, and the orthodoxy was right, because the margin ceiling came directly from labor intensity.

Take that intensity out and the model inverts. You get engagements that price like consulting and cost like product. Faster delivery means more engagements per unit of headcount, and (this is the part people miss) faster delivery also lets you charge more, because you’re now competing against a nine-month implementation, not against another consultancy’s rate card. Speed is worth more to the customer than it costs you to produce. Meanwhile the reusable substrate accumulates anyway. The fortieth engagement in a domain is mostly assembly.

The data has an interesting split in it, and the split is instructive.

Small firms are having a great decade. The MCA’s 2026 member survey found small and mid-sized consultancies crediting agility and tailored service offerings for their optimism, against sector growth forecasts of 5.7% for 2026 and 7.4% for 2027. Emergence Capital’s work on AI-native services describes the mechanism: 5 to 10x improvements in speed or throughput at 50%+ gross margins, with the richest opportunities in markets full of “stitch work” across multiple systems. Supply chain operations is on their list by name.

The large firms are not having the same decade, though the story there is more complicated than the headlines suggest. The Big Four and the strategy houses have poured money into AI since 2023, north of $10B by one industry tally, and the margin hasn’t followed: specialist AI talent commands a premium, and clients haven’t agreed to pay more for AI-accelerated work. Accenture took roughly $865M in charges across Q4 FY25 and Q1 FY26 for a “business optimization program” (largely severance tied to its talent strategy) while pursuing efficiencies including through AI, and is guiding FY26 revenue growth of 3 to 4% in local currency, or 4 to 5% excluding federal. Bloomberg reported McKinsey planning cuts of up to 10% in some areas over eighteen to twenty-four months, concentrated in non-client-facing roles, with headcount already down from a 2022 peak above 45,000 to roughly 40,000.

The honest caveat is that this is not the death of the pyramid, and anyone telling you otherwise is ahead of the evidence. McKinsey is simultaneously planning to grow North American headcount 12% in 2026, with junior ranks up as much as 20%. The cuts are landing in the back office, not on the analyst bench. What’s visible today is margin pressure and a pricing model under strain, not a collapsed operating model.

The lesson is still that AI rewards the firm with no pyramid to protect. Five people with real domain depth and agentic tooling now clear work that used to need thirty, and they keep the difference. The incumbents get the productivity and hand most of it to the client.

One caveat on “higher margins than ever,” because the number deserves precision. It means higher than services used to earn, not higher than software at its peak. ICONIQ’s surveyed operators expect ~52% average gross margin on AI products in 2026, up from 41% in 2024; Bessemer’s pricing work puts the band at 50 to 60% against 80 to 90% for classic SaaS. Inference is a genuine variable cost that doesn’t disappear with scale. But 52% and climbing, on work that used to be billed by the hour, is a far better business than the one it replaced.

The uncomfortable implication is that services businesses were always closer to what customers wanted. Nobody ever wanted software. They wanted the problem gone. Product was the compromise we made because bespoke was unaffordable.

What’s the difference between a configuration layer and a fork?

Everything above can be used to justify a company that is really just a consultancy with a product page. That failure mode is well documented. Every new customer needs bespoke engineering, delivery headcount grows linearly with logos, and the roadmap becomes a negotiation document. Emergence’s diagnostics are the honest ones to hold yourself to: gross margin flat or falling while revenue grows, revenue per employee not improving, delivery still human-heavy, bespoke work expanding as a share of delivery rather than shrinking.

The distinction that decides which company you are is whether custom work lands in a configuration layer or in a fork. Both look identical from the outside: a vendor that says yes. They have opposite balance sheets. If the tenth customer’s strange requirement becomes a configuration the eleventh can also use, fluidity compounds. If it becomes a branch, you just bought revenue with your own future.

Fluidity is not a sales posture. It’s an architectural property, and you either designed for it or you didn’t.

How did Arvist respond to WMS and ERP fragmentation in 2023?

In November 2023, on the back of our $1.1M pre-seed, Arvist’s CEO Nilay Parikh described the market to Sourcing Journal this way: the number of WMS and ERP platforms out there is enormous, and, unlike most software categories, it isn’t a handful of players holding large share. Material handling operations in particular run a wide spread of different systems. What he wanted was “a common way of integrating” rather than a custom build for every new customer.

Read casually, that’s a founder complaining about a hard market. It was actually a structural observation, and what you do with it determines your architecture. There were two available responses. Integrate deeply with the top three WMS platforms and abandon the rest: the vertical monopoly move, executed at startup scale. Or treat fragmentation as the permanent shape of the market and build for it.

We built for it, and not with one integration layer. Integration surface at every level of the stack, on the assumption that no two buildings, IT departments, or camera fleets will ever agree on anything:

° Sensors. Use the cameras already on the wall. Where new optics are genuinely required, QC in a Box deploys the day it arrives; no infrastructure project.

° Edge. An outbound-only appliance we own and maintain, so a customer’s IT team is never asked to open a port or host our containers, with a customer-hosted variant for the shops that insist on one. (The reasoning is in The Magic Wand Problem.)

° Camera protocol. Native ONVIF events and the camera’s own MQTT client rather than polling every device over RTSP, because the fleet is heterogeneous and always will be.

° Systems of record. 80+ WMS and ERP platforms out of the box, on the premise that the long tail is the market rather than an afterthought.

° Identity. Enterprise SSO for organizations with an IdP, email and magic links for those without, OAuth client credentials and service tokens for partners’ machines. Four populations, four front doors.

° Partners. Co-sell integration architectures with the incumbent video and access-control ° platforms instead of a pitch to replace them.

° Governance. ISO 27001 audit complete and SOC 2 Type II underway, because “we’ll bend to your workflow” only closes when it’s also auditable.

None of that is a moat in the boomer sense. We don’t own a category and we aren’t trying to. The bet is narrower and I think more durable: in a market with no dominant system of record, the vendor who can be reshaped fastest wins the next ten years.

Where does the vertical monopoly critique break down?

Three places, and they’re serious.

The fixed cost moved, it didn’t vanish. Two hundred bespoke deployments is two hundred things to keep running, on two hundred customers’ schedules, against two hundred sets of upstream changes. Creation got cheap; operation didn’t. Anyone running this playbook without an obsessive answer for maintenance is building a support obligation that eats the margin they thought they’d won. This is the failure mode, and it will kill more people than competition does.

Not all moats are made of code. Compliance, procurement, insurance, and brand don’t get cheaper because inference does. Enterprise buyers will still demand SOC 2 Type II from a four-person team, and no amount of delivery speed shortens a security review. Incumbents keep these advantages entirely. The strongest version of the counterargument (Stax makes it well) is that mission-critical vertical platforms are getting more entrenched, not less, precisely because the cost of owning software is rising. I think that’s right about systems of record. Manhattan isn’t going anywhere. The claim here is narrower: aspiring to become Manhattan is now the wrong ambition for a new entrant, because the value is accruing in the work surrounding the system of record rather than inside it.

Proprietary data still favors concentration. Where value comes from a dataset that only accrues at scale, the vertical logic holds. Some categories are genuinely like this. Fewer than the pitch decks claim, but not none.

What should software companies do differently?

The metric worth watching isn’t engineering output, it’s how fast a specific customer situation turns into something running in production. Those are different measures, and they reward different people.

Custom work isn’t a failure of productization on its own. What matters is whether it lands in a configuration layer or becomes a fork.

And the category itself is worth holding more loosely. Categories are the geography of a cost structure that’s already gone. The old question was what do you own? The new one is how fast can you be reshaped, and does each reshaping make you cheaper to reshape again?

Vertical monopolization answered the first question beautifully. It has nothing at all to say about the second.

FAQ

Why was vertical monopolization the default strategy in B2B software?
Software used to be expensive to build and nearly free to copy. That cost structure rewarded companies that could get one codebase adopted by hundreds of customers, which meant building the broadest possible system of record for a vertical and defending it.

Why is vertical monopoly no longer the optimal strategy?
The cost of producing software fell sharply with AI-assisted development, which collapsed the minimum viable size of a market. Niches that were once too small to serve profitably are now addressable, and the value is shifting from owning a broad system of record to being able to reshape quickly around a specific customer’s operation.

What’s replacing per-seat software pricing?
Consumption-based and outcome-based pricing are both gaining share as the atomic unit of value shifts from seats to work performed. Buyers are increasingly paying for a labor budget’s worth of output rather than a software budget’s worth of access.

What’s the difference between a configuration layer and a fork?
A configuration layer means a custom requirement from one customer becomes something reusable for the next one. A fork means it becomes a permanent branch that has to be maintained separately. Both look like “the vendor said yes” from the outside, but only one compounds in the vendor’s favor.

Is consulting still a low-margin business model?
Not when the labor intensity behind it drops. Removing that intensity lets services engagements price like consulting while costing closer to product, which is why small, AI-native consultancies are seeing margin and growth improvements that the traditional pyramid-model firms aren’t matching at the same pace.

If code is cheap to produce, what becomes the real competitive advantage?
Knowing what to build, having physical and organizational access to the problem, and being accountable for the outcome rather than just shipping a feature. None of those compress the way code does, which is what makes them valuable again.

Related content

Why Your Integration Quote Is Wrong The quote priced the connection. The work was always in the mapping. You were told four to six weeks for […]

...

.

5 mins
Learn how AI in logistics and supply chain improves efficiency by optimizing operations, reducing costs, & improving accuracy for smarter warehouse management....

.

9 mins

On-Prem vs On-Cloud If you have been running a business for more than five minutes, you have probably faced this question: should you keep your IT […]

...

.

3 mins

Please wait...