The Engine
A beta partner ran three reasonable requirements through the matching engine and it returned nothing at all. Here is what that broke, and what is underneath it.
The most complex beta partner in the program returned zero matches, and by zero I mean not a short list and not a weak list but nothing at all.
They were the reason I wanted an operation that size in the program at all. A multi-division heavy equipment dealer organization, thousands of employees across dozens of locations, with machines, rental, parts and service, power systems, and trucks all running under one roof, and each division carrying its own operating rhythm and its own systems. Complexity like that is not an edge case you design around later, it is the environment this platform has to survive in, and my thinking was that if the engine could not handle them it could not handle anybody.
They said yes because of a relationship rather than a pitch. Thirty years in this industry buys you exactly one thing that matters, which is that the people who let you inside their operation already know how you work. That is not a sales technique, it is the only currency that produces real requirements instead of polite ones, because a buyer who is being careful with you gives you the requirements they think you want to hear, while a buyer who trusts you gives you the three things that will actually kill the deal.
I got the three things, and the engine broke on them.
All three were reasonable, and all three were things the operation genuinely needed. The engine took them at face value, applied them as gates, and eliminated the entire vendor catalog.
The engine had done exactly what I told it to do. What it was telling me back was that I had told it the wrong thing.
Here is what I had backwards. When a buyer says a requirement is a must-have, they are telling you it matters a great deal. They are almost never telling you they would rather have nothing than have a system that covers four of their five priorities exceptionally well. Treated as walls, three reasonable requirements intersect into an empty set. Treated as weight, those same three requirements produce a ranked list where the vendors covering the most of what matters rise to the top.
So the engine converted. A buyer's stated requirements stopped acting as gates and started acting as weight, adding lift to the vendors that cover them, and the coverage compounds, so the vendor who satisfies all three outranks the one who satisfies two, who outranks the one who satisfies none. The buyer still gets the answer they were looking for, and they also get the four vendors they would never have seen, with the coverage gaps stated plainly so they can decide for themselves whether a gap is a dealbreaker or a negotiation.
Structural gates are a separate thing entirely, and those still remove vendors outright, as they should. Persona is a wall, because a system built for a private fleet does not serve a broker. Operational fit is a wall. Legality is a wall, and in ELD that means a device has to hold current standing on the federal register, verified on a recurring schedule, or it does not enter matching at all. Those are not preferences, they are facts about whether a vendor can serve you.
A few of the other design decisions are worth naming, because they are where most of the thinking went.
A vertical is data, not code. Each category runs as a pack with its own question bank, dimensions, personas, and weights, and all of them execute through one generic evaluator. Adding fleet management did not mean writing a fleet management engine, it meant writing a fleet management pack. That is why adding a category is measured in pack work rather than a rebuild, and why each new one costs less than the one before it.
It also keeps the packs comparable, because item numbering carries stable structural roles across every vertical. The confidential vendor exclusion is the same item in TMS as it is in dock scheduling, and market fit occupies the same block everywhere. A dimension means the same thing no matter which category a buyer is in.
Missing data never counts against a vendor. This one is subtle and it matters more than anything else on the list. Vendor capability is tri-state, meaning yes, no, and not yet measured, and the engine gates only on a known no. If we have not asked a vendor about something, that silence never becomes a penalty. The alternative would quietly punish the newest and smallest vendors for the sin of being newer to the reference layer, which is precisely the dynamic I built this platform to eliminate. Scoring follows the same rule, since fit is a weighted mean renormalized across the dimensions actually assessed rather than against a fixed denominator that assumes complete data nobody has.
The composite is an index, not a percentage. Coverage bonuses are additive and lift-only, so covering more of what a buyer needs can push a score past 100 and routinely does. Penalties are multiplicative and they compound, but they fire only when the buyer actually stated the constraint, so nobody gets docked for failing a test the buyer never asked for. A score above 100 is not a defect and we do not cap it.
What the index is really doing is exposing nuance, and that is the part worth understanding. In any mature category the leading vendors all do the obvious things competently, so if you scored only the obvious things you would produce ten vendors clustered within a point of each other, which tells a buyer nothing they could not have guessed. The separation lives in the edges. How a system handles the mode you run least often but cannot drop. Whether it supports the one integration your finance team will not compromise on. What happens to it at your volume rather than at demo volume. Whether its implementation model survives contact with the IT capacity you actually have rather than the one on the org chart.
Those edges are where vendors genuinely differ from each other, and they are also where the ranking gets decided, because every one of them is weighted against a specific operation rather than a generic one. Two buyers in the same category with similar headcount and similar spend can receive two different lists, and they should, because the nuances that matter to one of them are not the nuances that matter to the other. A ranking that produced the same five vendors for everybody would be a directory with extra steps.
Every scoring decision is written down and names its actor. The fact layer is append-only and immutable. Client answers, vendor facts, match lifecycle events, and scoring events are all time-stamped with attribution, and the record is self-describing rather than something you reconstruct later by correlating timestamps across tables. When a buyer asks why a vendor ranked third, the answer exists as a record rather than as a reconstruction.
The engine cannot see money. Payment-blindness is an architectural boundary rather than a policy commitment. The component that computes fit has no access to billing or commercial terms, so a vendor's economics cannot reach the match even in principle, and there is no configuration flag to flip.
Disclosure is computed live. A vendor sees a scoped slice of a buyer's assessment only after accepting the match, and what they see is computed from current state rather than from a snapshot taken at match time, so if a re-score changes the match the disclosure changes with it.
And a buyer can remove a vendor confidentially. If there is an incumbent relationship that went badly or a competitor they will not entertain, that exclusion never surfaces to the vendor. It is the buyer's platform.
Nothing in this market works this way, and I want to be precise about why rather than just asserting it.
A directory lists. A review site ranks by volume of opinion. An analyst grid ranks by vendor scale and market presence. Every one of them starts with the full field and sorts it, and none of them removes anybody. That is the entire difference and it is a structural one, because sorting sixty vendors tells a buyer who is popular, while removing fifty-five tells them who can actually do the work.
Two reasons this did not exist already.
The first is that the complexity is real. Everything above has to hold together at once, across every category on the platform, without the packs drifting apart and without a single scoring decision escaping the record. That is not a weekend project, and it took several hundred structured decisions plus beta partners across several categories telling me where I had it wrong.
The second reason matters more. The people who understand this problem well enough to specify it correctly have never had the means to build it. Operators do not write software, and until recently building this would have meant raising money, hiring engineers, and translating thirty years of operating knowledge through three layers of people who have never worked a dock or run a bid. Every hop in that chain loses something, and what it loses is exactly the nuance that separates a tool that fits from a tool that demos well.
That barrier came down. The cost to build fell far enough that the operator can build it directly, and this is what that looks like.
The gating conversion is the headline from that beta, but it was not the only thing that came out of it. Sitting inside an operation that complex surfaced questions the bank was not asking, personas that did not map cleanly to how a large dealer organization actually divides work across divisions, and a wrong assumption about who inside a big buyer really owns a technology decision. All of it went back into the packs. A beta is not a customer who tests your product, it is a customer who tells you what your product is missing, and you only get that from people who trust you enough to be blunt with you.
None of this is architecture for its own sake. It changes what happens in the room.
The buyer walks into the first call already aligned on what they need, with a list they can actually execute and reasoning for every removal. The vendor gets qualified early instead of three months in. Engagement cycles compress because discovery already happened. The scope of work gets written against documented requirements instead of guesswork, which is why implementations move faster and the surprises surface before the contract rather than after it. Cost avoidance arrives sooner and holds, because the system actually fits the operation it was bought for.
None of that is a claim about being clever. It is what happens when both parties start from the same set of facts.
The engine is more robust today than it was before that beta ran through it, and it is more robust specifically because they did. That is the case for building from the operating seat rather than from a whiteboard. A whiteboard would have told me the gates were correct. A real operation told me they were not.
Selecting supply chain technology?
PreShiftIQ matches buyers to vendors on measured fit across TMS, dock scheduling, ELD, carrier vetting, and fleet management. Vendors pay for outcomes, never for influence, and the buyer match is free.
See how matching works at preshiftiq.com/how-it-works.
Next in the series: I am not a developer, and I built this anyway.
