Delivery decision brief — the leadership decision on how bc-subscriptions ships¶

Generated from a canonical source

This page is a read-only projection of docs/strategy/delivery-decision-brief.md. Edit the canonical file, then run npm --prefix tools/project-knowledge-derive run derive.

Who this is for. The people deciding how subscriptions gets built and staffed — not how it works. This is the front door to the delivery-strategy corpus; the three instruments below carry the detail this brief only cites.

The three decisions on the table:

Architecture — full native (a BC platform service), full app (a marketplace app), or hybrid (a marketplace app that composes with a small set of new BC platform primitives).
Staffing — can the build be outsourced to an agency, and if not entirely, what internal resource must we keep on it?
Sequencing — how any of this contends with initiatives already in flight.

The one thing to take away: decisions 1 and 2 are the same decision, and the thing that resolves both is the same thing whose absence created the B2B Edition debt leadership is reacting to. Read on for why — then the recommendation, and the part only leadership can decide.

The unifying insight: the seam, not the "app," is what went wrong¶

The reference point in the room is B2B Edition — an app that became durable technical debt and a standing security cost. The instinct that follows is "don't build another app." That instinct targets the wrong variable.

The only primary-source account we have of the B2B concern is the Slack exchange that opened this whole question:

jordan: this is a separate 'bolt-on' app, as opposed to it being a first-class citizen… B2B Edition is a bolt-on/sidecar to the main app, and we're paying for it today.

Everything past that quote should be read as a structural risk pattern, not as a claim about what B2B Edition specifically did to its auth, data, or security — we don't have that record, and reconstructing it as fact would be exactly the kind of confident guess that misleads a decision.

The pattern is this: a bolt-on accretes debt when it owns its own integration seam — its own auth, data, and platform-coupling — and no internal architectural owner is retained to keep that seam converged with the platform. Nothing forces convergence, so drift compounds, and years later you are still paying for it.

That reframes both of leadership's first two questions into one:

"Will this become another B2B Edition?" → only if we ship a seam nobody internal owns.
"Can we outsource it?" → yes, if the seam's architectural ownership stays internal; no, if outsourcing means handing away the ownership too.

"App" is not the disease. An unowned seam is. An app with a retained internal architecture owner and native-ready discipline is not B2B Edition. And the inverse holds: a native service handed to a starved or absentee owning pod would accrete its own debt just as surely. The shape is not the risk; the retained ownership is.

What would have to be true — path by path¶

Matching the decision style of delivery-fork.md: the question is not "which path is best," it's "what would have to be true for each," and — the axis the fork doc under-weights — who can actually build it.

	Full native	Full app	Hybrid (app + platform shims)
What must be true	BC treats subscriptions as a platform-native capability and forms/assigns a pod to own it	The product is durably a marketplace offering; native graduation stays an option, not a plan	Same as app, plus BC will ship a small set of additive platform primitives on its roadmap
Who can build it	Internal pod only	Agency-buildable against public APIs	Split: agency builds the app; internal pods ship the primitives
Cost profile (from the gap matrix)	Highest — 20 dimensions rework A→B: 6 XL, 6 L, 7 M, 1 S	Lowest — the shape we already have	App cost + bounded platform work per primitive
Claim on internal capacity	Largest and permanent	Smallest — one architecture owner	Small for the app; real for the primitives (platform roadmap)
Repeats the B2B seam?	No — it is the platform	Only if no internal owner is retained	No — shims shrink the seam by design

Two facts inside that table carry most of the weight:

Native cannot be outsourced — and its ramp never ends. A native build depends on knowledge that lives only inside BC and largely behind BC GitHub access: gRPC contracts in bigcommerce/interfaces, bounded-context discipline, Domain Eventing on RabbitMQ, direct BigPay integration, and the Launchbay/Nomad/habitats deploy chain — with merchant-subscription-manager as the one existing structural precedent to study. An agency cannot ramp on any of that unsupervised, and the dependency on internal knowledge is not a one-time ramp — it is ongoing, because the service lives inside standards that keep moving. Native is an internal-pod commitment, full stop. (Detail: native-shape-gap.md.)

The app path is the only outsourceable one — because the prototype is the spec. A marketplace app consumes the public BC surface (/v3, GraphQL Storefront, Scripts API, Catalyst) — the surface partners build against by definition, so an agency can work it. And the ramp is bounded and front-loaded rather than open-ended, because the running storefront/admin/portal prototype in this repo is an executable specification: the agency builds against a working reference, not a blank brief. That asymmetry — native ramp is months and never ends; app ramp is weeks and then done — is the single strongest argument in the staffing question.

The hybrid path divides cleanly along the same line: the agency builds the app against public APIs, and internal pods ship the platform primitives that let the app stop working around the platform. Each primitive is a bounded, additive change to one BC domain (catalog, pricing, checkout, payments, eventing) — not a rebuild. The catch is sequencing: those primitives compete for platform-roadmap priority, which is leadership's third question. (Detail: delivery-shim-path.md.)

The guardrail exists — but it's built only halfway¶

The discipline that keeps "app-first" from becoming B2B Edition already has a name: native-ready (ADR-0029, a ratified decision record). It requires the app to follow BC's internal conventions — typed errors, the auth-principal envelope, snake_case wire, audit and entitlement patterns — so that if a graduation conversation ever opens, the lift is bounded to months, not years. The portability inventory is the evidence this is real and not aspirational: roughly 70% of the work to date survives either path unchanged, and only ~10% would need genuine rework on native.

But native-ready as written bounds the lift of a graduation without ever defining a trigger for one. ADR-0029 is explicit: graduation "is a future BC-side strategic call… not a partner-side decision," and "whether a graduation event ever occurs" is listed out of scope. Read plainly: the decision record makes the eventual move cheap but names nothing and no one that would ever call it.

That gap is the B2B trap, precisely. App-first that quietly becomes permanent — because the convergence conversation is bounded-but-unowned and so never happens — is the exact failure mode leadership is trying to avoid. Native-ready discipline closes half the trap (the lift). The other half — who owns the seam, and what event forces the convergence question — is undecided. That half is a decision for leadership, and it is the decision that separates "app-first, native-ready" from "another bolt-on."

Recommendation: app-first, native-ready — robust, not maximal¶

Ship the marketplace app, built native-ready, with two non-negotiables:

A retained internal architecture owner. One person (not a team, not the agency) owns the integration seam and the native-ready convention set, and reviews the agency's work against it. This is the resource whose absence created the debt leadership is reacting to — funding it is what makes "app" not mean "bolt-on."
A named graduation trigger — the ADR-0029 gap, closed. Write down the condition that would open the native conversation (e.g. subscriptions crosses a revenue or strategic-core threshold, or a pod is stood up), and who owns watching for it. Without this, app-first has no defined exit and drifts into permanence by default.

Pursue the platform primitives opportunistically, sequenced behind committed in-flight work, never ahead of it. Each primitive shrinks the seam and moves the product toward platform-citizen benefits without a rebuild — but because they claim scarce internal roadmap capacity, they are earned as priority allows, not treated as blocking.

Reserve full native for a strategic-core reclassification — the day BC decides subscriptions is a platform-native capability and staffs a pod for it. That is an organizational decision, not a technical one, which is exactly why it is leadership's to make and not the project's to assume.

Why this recommendation is robust rather than a bet: it survives losing the priority fight. If the platform primitives never win roadmap space, the plan degrades gracefully to a plain, native-ready marketplace app that still ships. If subscriptions is reclassified strategic-core tomorrow, native-ready discipline means the lift is bounded, not a restart. The recommendation is reversible in the only direction that matters — toward more platform ownership — and never traps the product away from it. That is what "support the decision" should mean here: not collapsing a genuinely open call, but making the default safe and every exit cheap.

What this asks of leadership¶

Three decisions, each with the fact that makes it decidable:

Architecture. App-first, native-ready is recommended — but it is only real if you fund the retained internal architecture owner. Fund that role, or the recommendation collapses back into the B2B pattern. This is the load-bearing decision.
Staffing. An agency can build the app; it cannot build native. The internal resource to pull is small but non-optional — one architecture owner/reviewer, not a team. Name that person. The prototype is what keeps their supervision load bounded instead of full-time.
Sequencing. App-first makes the smallest claim on internal capacity, so it contends least with in-flight initiatives. The platform primitives do contend, on the platform roadmap — sequence them behind committed work, as opportunistic upside, not as a blocking dependency.

The instruments¶

This brief is the altitude above these; each carries the detail and the primary evidence, and none is restated here.

delivery-fork.md — the app-vs-native fork, its trigger, and the "what would have to be true" criteria (the engineering-handoff framing)
delivery-shim-path.md — the hybrid path: the additive BC platform primitives, domain by domain, and what stays app-owned
native-shape-gap.md — the 20-dimension rework matrix, with the internal-knowledge dependencies that make native un-outsourceable
portability-inventory.md — artifact-level evidence that native-ready is real: what survives both paths, what is rework
platform-shims.md — the per-primitive feasibility catalog
ADR-0029 — the native-ready posture, and the graduation-trigger gap this brief flags