§ Decision · Scale

When single-yard tooling stops scaling.

Most dismantling software, including Sustain360's own Single Yard tier, is sized for one site. That is the right shape for an independent operator running one yard. It is the wrong shape for a dismantler group running three yards under one brand, or an aggregator running twelve yards across two markets. This article maps where single-yard tooling stops scaling, and what changes when the platform has to run more than one yard at a time. The structural answer is not bigger single-yard tooling — it is a platform whose tenant model expresses Aggregator → Dismantler → Yard from day one, and whose role model, reporting layer, and integration surface scale accordingly.

A multi-yard platform is what holds the network together once each yard refuses to run the same way.

1. What single-yard tooling assumes

Single-yard tooling assumes one workflow, one set of role assignments, one set of label templates, one currency, one VAT regime, one set of integrations, and one team that knows each other by name. Those assumptions are not wrong — they are right for a single yard. The simplifying assumptions are what make single-yard tooling fast, cheap, and easy to operate. A single yard does not need tenant hierarchy, scoped permissions, or cross-yard reporting; everything in scope is by definition in scope of one yard, and the platform can fit that shape exactly.

The trouble starts when a second yard joins under the same brand. The second yard has its own dismantling preferences, its own preferred storefront, its own scanner hardware, and its own way of running the binning station. Forcing it onto the first yard's tooling is rarely possible and never welcome. Single-yard tooling either fails outright at this point or accrues bespoke workarounds — duplicate tenants, exported spreadsheets to bridge between sites, manual reconciliation by the head-office team — that slowly recreate the multi-yard platform the group should have bought in the first place.

2. What changes at multi-yard

Three things change shape at multi-yard: the data model, the role model, and the reporting layer. The data model has to express tenant hierarchy — Aggregator → Dismantler → Yard — and let each yard own its own workflow without forking the platform. The role model has to scope each operator's permissions to their own yard while letting head-office staff see across. The reporting layer has to roll up by yard, by market, by channel, and across all of them at once.

  • Yard-level workflow customisation — each yard defines its own dismantling states and role assignments.
  • Tenant-scoped audit trails — every action records yard, operator, role, time, and value.
  • Concurrent FI and UK operations within one tenant.
  • Multi-channel listing across the storefronts each yard actually uses.
  • Head-office reporting roll-up, by yard or by network.
  • Centrally-administered integrations with per-yard credentials.
  • Single user lifecycle (SSO/SAML) across the network.

3. When the line gets crossed

The crossover point is usually one of three triggers. The first is a second physical site. Even one extra yard rapidly outgrows single-yard tooling once the workflows diverge. The second is a second market — running concurrent FI and UK operations is structurally beyond single-yard scope, because the localisation reaches into VAT, currency, compliance paperwork, and integration shape. The third is an integration ambition — a head-office team that wants to push a unified data warehouse, a corporate SSO, or a network-wide audit dashboard.

If you are within a year of any of those three triggers, multi-yard tooling pays for itself faster than the migration cost. If you are more than a year away, single-yard is the right answer.

4. Migration shape

Migrating from single-yard to multi-yard inside Sustain360 is a tier upgrade, not a re-platform. The same tenant, the same VINs, the same orders, the same audit history; what changes is the addition of the Aggregator and Dismantler levels above the Yard, the activation of yard-level customisation, and the onboarding of the additional yards. Most upgrades complete inside a quarter end-to-end. Customers arriving from external single-yard tools face a more standard migration on top.

5. Where roles diverge

Roles look the same on paper at single-yard and multi-yard scale — yard managers, dismantlers, inspectors, binning operators, sales, pickup, accounts, experts. The structural difference is the scope of permission. A yard manager at a single yard sees the whole tenant; a yard manager in a multi-yard network sees only their own yard, with cross-yard visibility reserved for the dismantler-group operations role above them. The role model has to express that scoping without forcing operators to relearn the system.

Head-office roles emerge at multi-yard. A central operations role oversees throughput across the network without running any one yard. A central compliance officer consumes the audit roll-up across all yards rather than per yard. A central accounts role reconciles across PayPal, every storefront, and every yard ledger from a single pane. None of those roles exist in a single-yard tenant.

User lifecycle also scales differently. A single yard often runs local accounts because the team is small enough to manage manually. Multi-yard networks usually move to SSO/SAML against a corporate identity provider — Entra, Okta, Google Workspace — with SCIM provisioning keeping the user lifecycle aligned automatically.

6. Reporting that holds the network together

The reporting layer is the surface that most reliably justifies the upgrade to multi-yard. A network running on per-yard reporting alone is a network running blind at the head-office level. KPI dashboards have to roll up by yard, by market, by channel, and across the network — and the dashboards have to respect tenant scope so yard-level operators see their own data and head-office staff see across.

Exception queues matter at network scale. A part that has been dismantled but never binned in any one yard is an isolated incident; the same pattern across five yards is a workflow problem. Multi-yard exception queues surface the pattern at the head-office level so it can be addressed against the relevant yards' processes, not chased one ticket at a time.

Material-recovery and producer-responsibility reporting roll up the same way. The numbers an aggregator submits to a producer-responsibility scheme are queries against the platform's existing data, not a separate authoring exercise — even when the source data spans twelve yards and two markets.

7. Where Sustain360 sits

Sustain360 ships three tiers — Single Yard, Multi-Yard, and Aggregator Enterprise — sized for the three operating shapes above. The platform's tenant model is Aggregator → Dismantler → Yard from day one; the tiers are the licensing and onboarding shape, not separate codebases. Yards upgrade in place without re-platforming.

The Single Yard tier is sized for one site, with everything one yard needs: the full eight-stage workflow, every integration, the rules-engine pricing, the audit trail, and the EU ELV / UK ATF paperwork. The Multi-Yard tier adds yard-level workflow customisation, the multi-yard dashboard, SSO/SAML, and cross-yard reporting. The Aggregator Enterprise tier adds concurrent FI and UK operations in one tenant, a named account team, and the integration depth aggregator-scale networks tend to need.

FAQ

Common questions

Book a walkthrough

From the resources hub,
to the yard floor.

A short walk-through of the configurable workflow, the aggregator–yard tenant model, and the integrations relevant to your stack.