Custom modules
Modules are opt-in capabilities the operator enables per-tenant via
platform.tenants.enabled_modules. Several map directly to existing Orchard
primitives (auto-ship → Stripe subscriptions; spec-sheet fields → the product
metadata JSON column).
Example: equipment-commerce modules
For an equipment-commerce tenant (e.g. wine-filtration systems — equipment plus a DTC product line, not an alcohol retailer), the likely module list:
| Module | What it adds | Rough size |
|---|---|---|
product-spec-sheets | Richer PDP fields (flow rate, micron rating, voltage, dimensions) + attachable PDF docs | ~1 day |
warranty-tracking | Per-unit serial numbers, warranty registration, claim pipeline, extended-warranty SKUs | medium |
service-booking | Tech dispatch: scheduling, service-area coverage, on-site charges via Stripe, recurring maintenance contracts | multiple weeks |
freight-shipping | LTL carrier integration for heavy/bulky systems (parcel default doesn’t cover freight) | medium |
b2b-portal | Trade accounts: negotiated pricing, net-30, PO workflow, quote-to-order | medium–large |
Each is scoped as a one-page spec, you confirm, then it’s built.
The module contract (status: designed, not shipped)
The pattern — publish an npm module that slots admin UI into Orchard’s shell at
documented extension points — is designed but not yet implemented. Until it
ships, custom features run entirely in your repo and backend; you just can’t add
a custom tab inside admin.theorchard.dev yet. You can still launch.