Strategy → Delivery shim path
Platform-collaborative shims as a peer lane.
The marketplace-vs-native fork (delivery-fork) is a useful binary but incomplete. A third sibling lane exists — small, typed, additive BC platform extensions that compose with our marketplace app to collapse marketplace-side complexity without committing to native graduation. This page establishes the lane, applies an eight-test architectural-principles screen, surfaces the three keystones that cascade through the catalog, and frames B2B angst honestly.
Filed 2026-05-27 · Trigger: orchestrator + operator analysis thread applying bc-promo-rules' "what needs to be true" + architect challenge + architectural-principles re-test discipline · Source authority:docs/strategy/delivery-shim-path.md
Lane 1
Pure marketplace
Our worker only. Zero BC platform change. Ships at marketplace cadence. Fails on shadow-store drift, monkey-patching, brittleness against roadmap changes.
Lane 2 — this page
Shim (collaborative)
Our worker + BC platform extensions. Small, typed, additive shims in named bounded contexts. We own lifecycle; BC owns the seam. Fails on BC ratification velocity; cascade dependency on keystones.
Lane 3
Pure native
bigcommerce/bigcommerce + BC services. BC pod ownership. BC roadmap claim required. Fails on bounded-context coordination cost; staff-engineer dependency.
Lane comparison
Three sibling options across seven dimensions. The decisive test: each lane has a failure mode neither of the others has — that's what makes shim a peer, not a modifier on the existing marketplace/native fork.
| Dimension | Pure marketplace | Shim (this page) | Pure native |
|---|---|---|---|
| Code home | Our worker only | Our worker + BC platform extensions | bigcommerce/bigcommerce + BC services |
| Lifecycle owner | Us | Us; BC owns the seam | BC pod |
| BC platform change | None | Small, typed, additive | Deep, bounded-context ownership |
| Write-off exposure | None on shim; ~30% on app if Path B ever called (delivery-fork) | Same as marketplace for app code; zero on shim itself | Owned by BC |
| Ecosystem benefit | Us only | Every BC app + merchant | Every BC merchant |
| Political cost | Low | Medium (per-ask BC-team coordination) | High (BC roadmap claim, pod staffing) |
| Failure mode | Shadow-store drift; monkey-patching; brittleness vs roadmap | BC-side ratification velocity; cascade dependency on keystones; back-door-native if asks name our domain | BC roadmap claim risk; bounded-context coordination cost; staff-engineer dependency |
Architectural-principles preconditions
Eight tests every candidate shim must pass to qualify. Failing any one reclassifies the candidate as native (federation/behavior/policy ownership) or pure-app (we should just own it). Applying this screen to a first-pass shim list reclassified four candidates as native (including the B2B Edition federated identity headline) and two as pure-app.
| # | Test | Rule |
|---|---|---|
| 1 | Single bounded context | Change sits inside one existing context's natural boundary; doesn't federate across multiple. |
| 2 | Existing extension pattern | Reuses a documented extension point; doesn't invent a new one. |
| 3 | Single source of truth | Replaces our shadow store with first-class data; doesn't create a second source that will drift. |
| 4 | Data, not behavior | Fields, structured slots, contract additions are shim-shaped. Policy decisions and lifecycle ownership are native-shaped. |
| 5 | Public-goods | Benefits every BC merchant + app — not only us. |
| 6 | Doesn't implicitly anoint our domain | General-mechanism asks (sanctioned-app-emitted events, marketplace-declared extension contexts) — not domain-named surfaces. |
| 7 | Forward-compatibility | Ages well against known platform roadmap. The 2H'26 checkout billing-step replanting is the canonical anchor. |
| 8 | Reversibility | Can be deprecated cleanly if usage doesn't materialize. |
The three keystones
Per-shim analysis lives in the feasibility catalog. Three shims cascade through the rest — ratifying any keystone unlocks a cluster of dependent shims that have been stalled waiting for it.
A1 · Catalog
product.recurrence_options (Catalog)
9 of 15 catalog-domain shims cascade from this. Storefront slot (A11), cart line-item (A3), search facet (A13), channel-scoped pricing (A14 via A2) all derive from A1 being first-class catalog data.
A8 · Payments
authorize/capture adapter split (Payments)
The entire payments cluster depends on this. Capture-on-ship (EU), dunning, partial-period billing, refund/void semantics all gate on the adapter contract supporting deferred capture. Converts ADR-0038 to interim status.
A15 · Domain Eventing
sanctioned app-emitted MES event topic (Domain Eventing)
Unlocks webhook + email template extensions without back-door-anointing subscriptions as native. We emit; platform amplifies. Universal mechanism that benefits the whole marketplace ecosystem.
Misclassified-as-shim: actually native
Four candidates that looked shim-shaped but failed Test 1 (single bounded context) or Test 4 (data, not behavior). Pursuing them as shims would produce platform entanglement without delivering the value claimed.
B2B Edition federated identity [HEADLINE]
Federating B2B Edition's separate GCP Postgres + auth domain into the checkout context is a resolver crossing three bounded contexts (B2B + Customers + Checkout) — not a field extension. Calling this a shim hides the real scope. B2B-on-subscriptions is blocked-on-other-team where the team is a tripartite.
Customer-scoped recurring-consent ledger
Consent policy ownership is compliance/legal — not a data field. BC owning a consent ledger means BC accepting liability for its completeness. We own the ledger in our app; A4 is the opaque thread between cart and our ledger.
Inventory holds for subscription commitment
A counter without oversell policy creates drift. The behavioral question (cancel? notify? substitute?) is Inventory-domain ownership, not a configuration surface for an external app.
Mixed-cart recurrence policy
The behavioral decision (split? force-single? error?) is owned by Cart's bounded context. Interacts with order creation, fulfillment, tax, promotions — requires Cart-domain ownership, not external configuration.
Misclassified-as-shim: actually pure-app
Two asks we should stop trying to externalize. The platform doesn't need to know.
Retry-aware idempotency at platform level
Retry discipline is per-implementation; platform enforcement creates worse drift than the workaround. We own it in our worker.
Platform-computed LTV / subscription_count fields
Derive from our state. If BC computes, BC ingests — two-way coupling. Surface in our app, not on the customer record.
Implementation readiness
Honest verdict using the bc-promo-rules ready/conditional/blocked vocabulary. The B2B reframe is the headline: "Phase 3, deferred" was the wrong frame. The right frame is "blocked-on-other-team regardless of shim ambition."
A1 + A8 + A15 ratification unlocks the keystone cluster. The remaining 12 shims become inspectable asks with named team owners.
Cascade shims (A3/A4/A11/A13/A14 on A1; A7/A9/A10 on A8) ship as their keystone ratifies. Conditional on keystone velocity, not on independent decisions.
Blocked on identity federation (C1 — tripartite Customers+B2B+Checkout). Not solvable by any shim regardless of ambition.
Blocked on B2B Edition + Payments cross-domain commitment.
Blocked on BigCommerce Insights team commitment.
Recommendation
- File the three keystones (A1, A8, A15) as inspectable BC-side conversation topics with named team owners — Catalog, Payments, Domain Eventing.
- Continue marketplace-app delivery in parallel. Shim ratification accelerates value but does not gate shipping.
- Treat the B2B reframe honestly in stakeholder communications: B2B-on-subscriptions is blocked-on-other-team regardless of shim ambition. The right next move is filing a B2B identity federation initiative independent of subscriptions.
- Convert ADR-0037 (stored-instruments Vault popup) and ADR-0038 (capture-timing) to interim status via
[Decision]Hive proposals — they're superseded conditionally by A9 and A8. - File a
[Spec]Hive proposal to extend fork-aware priority to three tiers: portable > shim-collaborative > substrate-A. Shim-collaborative outranks portable because of compound ecosystem benefit.
References
- docs/strategy/delivery-shim-path.md — sibling strategy doc; per-section authority
- docs/feasibility/platform-shims.md — full 15-shim catalog with BC team owners, ADR citations, gating verdicts
- /strategy/delivery-fork — the marketplace-vs-native binary this lane extends
- METHODOLOGY-AMENDMENTS.md — three-pass research discipline + back-door-native anti-pattern + peer-vs-modifier test
- ADR-0029: Marketplace-first, native-ready — encodes the binary this page extends