Comparison
ManyRows vs Duro
Duro and ManyRows want the same thing: PLM that a small team can actually run. Duro gets there by building deeply for hardware, with CAD plugins and a component library that already knows what a resistor is. ManyRows gets there by letting you shape the system — which is what you want when the product is a garment, a formula, or several different things at once. The shaping goes deeper than custom fields: a typed data platform underneath, with base types, references that accept any member of one, BOM lines you design, and rollups that answer what expires soonest anywhere in a build.
What it is shaped for
| Capability | ManyRows | Duro |
|---|---|---|
| Hardware and electronics Duro was built for hardware teams and it shows. If you are building a device, it deserves a serious look. | Works | Purpose-built |
| Electronic component library with parametric specs Duro ships categories that already know a resistor has a resistance and a package. In ManyRows you define those fields once and reuse them — more setup, and it works the same way for a fabric or a flavour. | Modelled yourself | Purpose-built |
| Apparel, footwear and soft goods Size specs with grading and tolerances, per-season time and action calendars, colourways, mills and factories. | Purpose-built | Not its focus |
| Food, cosmetics and other formulations Percentage recipes with co-products and by-products, yield and absolute yield, and quantities fixed per batch rather than per unit. | Purpose-built | Not its focus |
| Define your own record types A lot, a sample, a piece of equipment, a garment, a season — same tools as a part, no feature request and no release. | Yes | Hardware-shaped schema |
The data model underneath
| Capability | ManyRows | Duro |
|---|---|---|
| Entity types, and base types over them Fabric and Trim are both Materials: a field defined once on the Material base type lands on every member, and a BOM line pointed at Material accepts either one. A type can belong to several base types at once, so Fabric is a Material and a Purchased Item and carries both sets of fields. Duro's categories arrive already knowing what an electronic part is, which is quicker if that is your product and immovable if it is not. | Both, in a form | Hardware categories |
| One field, reused across types, tuned per type Country of Origin is a single field attached to Fabric and to Trim — mandatory on one, optional on the other, with different defaults. It stays one field, so filters, facets and CSV columns line up across types instead of being five look-alike attributes that never quite match. | Yes | Category specs |
| Derived fields that follow a reference A lookup pulls the supplier's country onto every part that references it. A reverse field shows a supplier every part pointing at it, with nobody maintaining the other side of the link. | Reverse and lookup | Not its focus |
| Relationships that carry their own data A relationship type is backed by an entity type of its own, so the link between two records holds fields — dates, roles, quantities, notes. Cardinality is declared, and a self-referencing relationship rejects cycles rather than letting a tree close on itself. | The link is a record | Not its focus |
| The BOM line is a record you design The junction is a real type, so a line carries whatever the work needs and orders itself by an item-sequence field if you want the 10, 20, 30 convention. An optional role field turns a structure into a formula — primary, co-product, by-product, ingredient — with yield per line and absolute yield derived from it. | Yes | Line attributes |
| Rollups past cost and mass Total for mass, longest chain for lead time, earliest date for “what is the soonest expiry anywhere in this build”, and worst case over a flag for “is this whole assembly compliant”. Point the same engine at any numeric, date or flag field you have defined. A component with no value is reported as a gap rather than counted as a zero or a pass. | Four modes | Cost rollup |
| Effectivity on two axes at once A record can be valid between two dates and between two build numbers independently, and the structure lens applies both together — so “what was in build 400” is a question the BOM can answer directly. | Dates and unit numbers | Revisions |
| Someone to build the model with you Send a spreadsheet, a spec or an export from whatever you run today and we will turn it into types, fields, base types and BOMs with you. Duro will help you get started as well — small vendors do — and the difference is mostly that here there is more to decide, because the shapes are yours rather than theirs. It comes with Pro and above, and within reason means a first pass and teaching you to run it, rather than becoming your data team. | Free on Pro and above | Guided onboarding |
Getting data in
| Capability | ManyRows | Duro |
|---|---|---|
| Native CAD plugins (Altium, SolidWorks, Onshape) This is Duro's clearest advantage and worth being plain about: push a BOM from the CAD tool without leaving it. ManyRows does not have plugins. | No | Yes |
| Import a BOM from a CAD or spreadsheet export Drop in the indented CSV your tool exports — level column, dotted item numbers or plain indentation, all read. Parts match on part number, so re-importing after a design change updates the tree instead of duplicating it. | Built in | Built in |
| Automatic part numbering schemes Per-type prefixes and sequences, with the year in the number if you want it there. | Yes | Yes |
| Full REST API on every record Not only the record: its revision history, the spec it's judged against, its quality record, its schedule and its material requirements are all readable by an integration. | Included | Included |
| Outbound webhooks when something changes Register a URL and we POST to it the moment a record changes or a governed change is approved — HMAC-signed so you can prove it came from us, retried with backoff if you're down, and every attempt visible in the app. You set it up yourself; there's no middleware in between. | Built in, signed | Via API |
Product structure
| Capability | ManyRows | Duro |
|---|---|---|
| Multi-level BOM | Yes | Yes |
| Where-used, multi-level | Yes | Yes |
| Approved alternates per line | Yes | Yes |
| Formulas with co-products and by-products Primary, co-product, by-product and ingredient roles, with yield per line and absolute yield derived from it. | Yes | Not its focus |
| Fixed vs variable line quantities A catalyst or setup charge is needed once per batch, not once per unit, and the requirements explosion knows the difference. | Yes | Not its focus |
| Several BOM planes per product A materials BOM and an operations sheet on the same item, authored separately. | Yes | One structure |
| Compare two BOMs or two revisions side by side | Yes | Yes |
Change control
| Capability | ManyRows | Duro |
|---|---|---|
| Change orders with approvals Edit a working copy, compare it with what is live, approve it and the whole change applies at once. | Yes | Yes |
| Staged approvals with quorum Engineering signs before brand, and a stage can need two of three rather than everyone. | Yes | Approvals |
| Delegation and departed-approver handover An absence does not jam a change request, and someone leaving does not strand one — their obligations move to the author rather than sitting on a person who no longer has an account. | Yes | Approvals |
| Several change requests released as one decision Re-spec the connector and relabel the six assemblies that use it: reviewed separately by the right people, released together in a single transaction. | Yes | One at a time |
| Immutable revisions with the sign-off manifest Every approved change welds a revision recording who signed and when — kept even though the change request itself is cleaned up. | Yes | Yes |
Beyond engineering
| Capability | ManyRows | Duro |
|---|---|---|
| Costed BOM with wastage and landed cost Rolled cost, extra cost lines, mixed currencies converted at read, and labelled cost snapshots you can compare later. | Yes | Yes |
| Test rounds with verdicts and dispositions Use as is, rework or scrap, with a concession expiry and an owner and due date for the follow-up. | Yes | Not its focus |
| Measured values against a spec Every value keeps the limits it was judged against, so tightening a spec later never rewrites last quarter's results. | Yes | Not its focus |
| Time and action calendars Anchored to a date on the record, counted back, with dependencies and overdue notifications. | Yes | Not its focus |
| Lot genealogy and recall trace | Yes | Not its focus |
| Product content out to sales channels Channels, listings and per-channel pricing are being built onto the same record that carries the BOM and its change history — one product record rather than a PLM and a separate catalogue kept in step by hand. | Native, in build | Not its focus |
Cost and control
| Capability | ManyRows | Duro |
|---|---|---|
| Free trial Sign up and be inside the product in a minute, without a call first. Paid plans start after the trial, and every price is listed. | 7 days, no card | Trial |
| Price you can work out yourself Plans, seats and limits are published, so you can decide whether it fits before speaking to anyone. | Listed on the site | Quoted per seat |
| Export the whole project and re-import it Schema, records, BOMs, specs, quality history and calendars, as a bundle you can move between projects. | One request | Export tooling |
| Add a field yourself | Yes | Yes |
| Custom development when something is genuinely missing Ask before you assume it is a no. When the gap is something ManyRows should have anyway — a field type, an import format, a calculation, an export — we build it and ship it to everyone, at no charge. Duro is a small team that listens as well, so the difference is less about speed than direction: a request that is not hardware-shaped is off their path and squarely on ours. It is included from the Pro plan up, and within reason means it has to belong in the product for other customers too; if it does not, you get a straight no. | Free on Pro and above | Roadmap request |
When Duro is the right answer
If you build electronics and want a BOM pushed straight out of Altium or SolidWorks, and a component library that already understands parametric part specs, Duro is purpose-built for that and further along than we are. ManyRows is the better fit when your product is not only electronics, when you need quality records, costing and calendars in the same place, or when you would rather define your own types than fit into someone else's.
Questions
- How is ManyRows different from Duro?
- Duro is built for hardware teams, and for a pure electronics product it is a strong choice — its CAD plugins and its component library with parametric specs are genuinely ahead. ManyRows is a typed platform you shape yourself, so it covers products Duro is not centred on: garments with graded size specs and season calendars, formulations with co-products and yield, and portfolios holding several of those at once. It also goes further past engineering, into quality records, costing, calendars and channel content.
- Does ManyRows integrate with CAD?
- Not with plugins. ManyRows reads the indented BOM that mechanical and electronic CAD tools export as CSV, including level columns, dotted item numbers and plain indentation, and matches parts on part number so a re-import after a design change updates the assembly instead of duplicating it. If you want a button inside Altium or SolidWorks, Duro has that today and ManyRows does not.
- Should I choose Duro instead?
- If you are a hardware team building electronics, want CAD plugins and a component library that already understands your parts, Duro is purpose-built for that and worth the money. ManyRows is the better fit when your product is not only electronics, or when you need quality records, costing and planning in the same system.
- How capable is the underlying data model?
- The PLM is an application built on a general typed content platform, which is why it bends to your product rather than the other way round. Entity types are the concrete things you track — Fabric, Trim, Ingredient, Lot, Sample. Base types group them, so one field definition serves several types and a reference can be pointed at the base type to accept any member. Fields are reused across types with per-type overrides, so the same Country of Origin can be mandatory in one place and optional in another and still filter as one column. Links between records are records themselves, so a relationship carries its own fields. A BOM line is a type you design, and a role field turns a structure into a formula. Rollups run in four modes, including earliest-date and worst-case-over-a-flag, so “what expires soonest anywhere in this build” and “is this whole assembly compliant” are configuration rather than custom code. Duro reaches its speed by deciding the shapes for you; this reaches it by making the shapes cheap to declare. And if the modelling is the daunting part, we will do the first pass with you — send a spreadsheet or an export from whatever you run today and we will turn it into types, fields and BOMs — included from Pro up, within reason.
- What if ManyRows does not do something we need?
- Ask us — we do custom development for free on the Pro plan and above, within reason. If the gap is something ManyRows should have anyway, we build it and ship it to every customer rather than leaving it in a private branch for you. That is exactly why it costs nothing: your gap makes the product better. It is also the limit — we will not build a one-off that only you would ever use, and we will not promise a date we cannot hold. Where this tends to matter against Duro is when the thing you need is not hardware-shaped: a grading rule, a season calendar, a yield calculation.
- What does ManyRows cost?
- Pricing is published on the site — plans, seats and limits — with a 7-day free trial that needs no card, so you can work out the cost before speaking to anyone.
- How does this connect to our ERP?
- Two ways, and you can use both. Pull: a REST API over records, BOMs, revisions, quality records, specs and schedules, authenticated with a project API key. Push: outbound webhooks, so your ERP hears about a change when it happens instead of polling for it — signed, retried, and with a delivery log you can check. Neither needs an integration platform in between.