Skip to content
opsveraopsvera
Strategy
2026-08-11 · 3 min read

Why we started with supply chain instead of a generic platform

The case for a vertical wedge when your competitors are all selling horizontal.

The obvious move in this category is to build a horizontal platform. Document in, structured data out, connectors to everything, and let each customer configure their own workflow. It demos brilliantly, the market is enormous, and every investor deck can draw the same graph.

We went the other way, and the reasoning is worth writing down — partly because it explains what we will and will not build for you.

Generic platforms push the hard part onto you

A horizontal product has to be indifferent to what your document says. That sounds like flexibility. In practice it means the product handles the parts that are the same everywhere — reading text, offering a field mapper, calling an API — and leaves you the parts that are different, which are the parts that are hard.

Your SKU codes do not match your supplier's. Your approval threshold depends on value bands that depend on the customer. Your "short shipment" has a specific meaning that determines who gets told and how fast. A generic platform gives you a configuration screen for each of these and calls it empowerment.

What actually happens is that the workaround becomes a permanent job. Someone on your team owns the mapping spreadsheet forever.

Configuration is how a product hands its hardest problem back to the customer and charges them for the privilege.

Depth is only possible if you know the domain

There is a second problem, quieter and more damaging. To decide what an agent should do when a document is ambiguous, you have to know what the document means.

Should a quantity variance of twenty units stop the process? It depends whether this is a commodity with a known tolerance or a serialised item where twenty is absurd. Should an unmatched SKU be resolved by fuzzy match? Not if a wrong match ships the wrong thing to a customer.

Those calls cannot be made by a product manager who has never watched a three-way match. They have to be made by someone who has, and the only way to have that judgement across every industry at once is not to have it anywhere.

Pick one vertical and you can be specific. Pick all of them and you are reduced to giving the customer a rules engine.

What makes supply chain the right one

It was not chosen from a market-size spreadsheet. Three things made it obvious.

Why this vertical

  1. 01Document-heavy by nature — POs, invoices, ASNs, delivery notes, customs paperwork, most of it unstructured and much of it scanned
  2. 02High daily frequency, so a saved minute compounds instead of being a rounding error
  3. 03A wage bill attached to the work, which makes the arithmetic obvious to the person approving the spend

That combination is rarer than it sounds. Plenty of industries are document-heavy but low frequency, where nobody is losing hours a day. Plenty are high frequency but already structured, where the input arrives as clean API calls and the problem was solved a decade ago. You need both, plus a real cost attached, before automation is worth anyone's attention.

And the fourth reason is simply that we have already lived inside it. Years spent building and running order management infrastructure meant watching operations teams do exactly this manual work — and watching automation attempts fail in the same place every time, because the input was a badly scanned PDF and not a clean API call.

Vertical does not mean narrow forever

The part people get wrong about a vertical wedge is assuming it is a permanent ceiling. It is not. Underneath any of these workflows sits the same machinery: ingestion, extraction with confidence, a resolution layer, an approval gate, idempotent execution, an audit trail.

That machinery is domain-agnostic. What is domain-specific is the layer on top — what the fields mean, which variances matter, who owns an exception. Building that layer properly for one industry is how you find out what belongs in the machinery and what does not.

Build a workflow three times and the pattern is real. Build it once and generalise anyway, and you have guessed.

What this means for you

Practically: we will go deeper on your workflow than a horizontal product can, and we will say no to things outside it. If you are a freight forwarder or a 3PL, the person on your call will already know what an ASN is and why a partial receipt is not an error.

If you are in an industry we have not worked in, the reliability machinery still applies and the domain judgement does not. We will tell you that on the call rather than after the invoice.

That is a smaller promise than a platform makes. It is one we can keep.