How we classify, verify and rank
Every rule on this page is enforced by code that runs before the site can be published. If a record breaks one, the build fails rather than the claim going out.
The six Full MRP tests
All six must pass, each backed by a first-party source.
A product may be labelled Full MRP only when first-party evidence shows all of the following. “Unknown” never passes a test, and a capability claimed without a source counts as a failure, not a maybe.
- 1It represents a bill of materials, recipe, or formula.
- 2It accepts dated demand, sales orders, a forecast, or a master production schedule.
- 3It nets that demand against stock on hand and orders already incoming.
- 4It explodes requirements through at least one level of the bill of materials.
- 5It uses lead times or required dates.
- 6It produces dated buy, make, transfer, release, or reschedule recommendations.
If the evidence shows only recipes, stock deduction, low-stock alerts, builds or production batches, we classify the product as Light manufacturing or BOM & inventory instead. That is a statement about what we could verify, not a judgement about quality, and every product page shows exactly which tests it passed and why the others failed.
The class says what kind of system a product is; the tests say whether it plans. A broad ERP whose documentation clears all six tests keeps its Manufacturing ERP class and carries a “Passes all 6 Full MRP tests” badge, because both things are true. The directory filter of the same name finds every product that passes, whatever its class.
Test four needs its own evidence. A bill-of-materials editor, a nested structure or a recipe shows that a BOM exists, not that a planning run turns demand for the finished item into requirements for its components, so a record passes explosion only when a source describes that step, and we note any setting or edition it depends on.
A failed test is not a “No”. Each test on a product page shows one of three results: passed; not established, where the evidence is partial, missing or too weak to carry the label; and does not meet, which we use only when the vendor’s own material shows the product does not do it.
Yes, Partial, No, Unknown
Four values, and the difference between two of them matters most.
- Yes
- A first-party page states this capability, and we link to that page. Every Yes on this site carries at least one source.
- Partial
- Something related exists, but not the full capability as we define it, or it is available only on a higher tier, or as a paid add-on. The note says which.
- No
- We found explicit evidence that the product does not do this. We use this sparingly, because absence of evidence is not evidence of absence.
- Unknown
- We have not found first-party evidence either way. This is our gap, not the product's failing, and it never counts as a match in filters or the finder.
The most important rule on this page: we never turn missing evidence into a No. If we have not checked, we say Unknown and publish a list of exactly what we still want to confirm on the product page.
Vendor videos. A demo on the vendor’s own YouTube channel counts as a first-party source, on three conditions.
- The vendor has to be the one speaking. A customer testimonial or a talk by a partner is a lead we follow up, not evidence.
- The link says it is a vendor video, gives the year it was published, and opens at the moment the claim is made, for example “Vendor video, 2026, at 2:07”.
- A video from before 2023 can fill a gap in the capability table, but it cannot pass a Full MRP test on its own. Software changes too much in a few years for an old demo to carry that label.
Other limited sources. The same rule covers a vendor’s source code or developer notes, a vendor blog post, and a single marketing sentence. Each can fill a gap in the table, and its link says what it is and when it dates from, for example “Vendor blog, 2021” or “Source code, read 2026”. None of them passes a Full MRP test unless another source backs it.
Hands-on. Some claims come from an editor using the product in a signed-in account. Those links keep the page name and add “hands-on, signed in” with the month of the walk, because you can’t open them yourself and what they showed depends on that account and that date. Where a claim has been reviewed on its own, the table also shows the date it was last reviewed, separate from the date the whole record was checked.
What Verified means
77 of 166 records currently qualify, all of them among the 139 published in the directory. The other 27 are candidates still being researched.
Verified is a statement about evidence, not an endorsement. It means an editor checked the record against the vendor’s own pages. It does not mean we recommend the product, and it cannot be bought.
A record earns the badge only when all four of these hold:
- At least 50% of the 25 capability fields are resolved, a record too thin to be useful cannot be Verified however well sourced it is.
- At least 80% of the answers we display carry a first-party source link.
- At least 2 first-party sources are recorded for the product overall.
- The price structure is accounted for: a source link where the vendor publishes prices, or a written explanation where they do not.
- Verified
- An editor checked the class, status, pricing structure, and at least 80% of the shown capability claims against first-party pages. It is not an endorsement.
- Partially verified
- Identity and core capabilities are sourced, but pricing or several comparison fields are still unknown.
- Research queue
- A candidate record awaiting editorial review. It appears only in the clearly labeled research queue.
How we handle pricing
Two numbers, because one of them is usually misleading.
Where a vendor’s advertised price excludes the manufacturing capability you came for, we show a second figure. The useful entry price, and explain the gap. Several products in this directory cost four or five times their headline number to use for manufacturing.
We also record, and display, everything that moves the real bill:
- whether the price is per user, and whether there is a seat minimum;
- which add-ons are required to get the capability;
- whether the advertised rate assumes annual billing;
- onboarding and implementation fees;
- what a free plan caps, items, users, orders, integrations or history.
Every price carries the date we checked it and a link to the page it came from. We never calculate a “real price” when a required input is unknown; we show the pieces we have and say what is missing.
Where the Internet Archive kept copies of a vendor’s pricing page, the product page also shows a short price history: what the vendor charged before, and when it changed. Each line links the archived copy it was read from.
How match scores work
Deterministic and inspectable. No model, no popularity signal.
The guided finder first sorts every product into four groups by your must-haves and budget. A confirmed match meets each one on current evidence: a sourced Yes, and for “tell me what to order and when”, all six planning tests. A conditional match has nothing ruling it out but depends on something, such as Partial support, a free plan’s limits, an unpublished price, or a price in another currency, and the result says which. Not verified means we have no evidence either way on a must-have. Does not match means the evidence says no or the known price is over your budget.
Inside each group, products are ordered by the fixed weights below. The weights never move a product from one group to another. There is no machine learning here and no popularity input, popularity is not quality, and a product with more customers is not thereby a better fit for your shop.
- 40%Required capabilitiesWhat you told us it must do.
- 25%Manufacturing style and industryWhether it is built for your kind of work.
- 15%Team size fitAdjacent bands score partial credit rather than zero.
- 15%Budget fitWhere we have modeled a product's plans, we price the cheapest plan that includes what you ticked, with its add-ons, included seats and seat blocks, at both ends of your team size, and show the first-year cost next to the monthly one. Otherwise we use the useful entry price. A free plan fits only on its own limits, an unpriced required fee makes the total a lower bound, and prices in other currencies are not compared with a dollar budget.
- 5%Licensing preferenceOnly applies if you asked for open source.
Every product in every group is listed with the reason it landed there, because “why isn’t X here?” is the question people have. Unknown values never count as matches.
We do not publish a context-free “best MRP” ranking. There is no such thing: the best product for a two-person candle studio and the best for a twenty-person machine shop have nothing in common.
Money, and what it cannot buy
- Organic results are never sold. No vendor can pay for placement, a better match score, a Verified badge, or the removal of an editorial note.
- Sponsorship, if we ever run it, will be labelled “Sponsored”, visually separated from organic results, and will not affect sort order or match scores. A sponsor cannot display the Verified badge unless it independently meets the rules above.
- Affiliate links, if introduced, will carry a clear disclosure and will not change editorial content or ranking. As of today there are none.
- Vendors may submit corrections with evidence and we welcome them. That is what the correction form is for. They may not have a critical editorial note removed simply because they dislike it.
How a record gets published
Every record is a file in version control with a full history.
- 1A new or changed product record is proposed as a pull request against a JSON file in the repository.
- 2Schema validation runs automatically. A displayed price without a source or a check date fails the build.
- 3A record labeled Full MRP that does not pass all six tests with sources attached fails the build.
- 4A record labeled Verified that does not meet the four evidence rules fails the build.
- 5A product called open source without an SPDX license and a license or repository link fails the build.
- 6A preview deployment allows visual review before anything is merged.
- 7Merging publishes the change and updates the sitemap.
Think we got something wrong?
We would rather be corrected than be wrong. Point us at a first-party page and we will update the record.