Coffee Kit: subscriptions evidence and route decision

Research date: 12 November 2026. Scope: public documentation, supplied briefs, the recovered thread and local market aggregates. No app implementation, installed-provider test, merchant mutation, payment attempt or outreach was performed.

1. Decision in plain terms

Do not commit to a $99 subscription overlay before proving that its extra value survives the provider bill. Keep three routes open, with different customers and promises.

1. Purchase-only UX over existing plans is the smallest useful route for merchants happy with their engine. Coffee Kit can connect coffee discovery, grind/size/quantity choices and enrollment. This does not deliver automated limited-lot replacement. Price the complete catalog/presentation/discovery kit on its demonstrated value; a nicer subscription selector alone is a weak $99 proposition.
2. Deep provider orchestration is credible with affordable, documented APIs. Prioritize Seal, followed by Appstle's approved partner route, and support Recharge where an existing merchant's workflow warrants it. Loop/Skio are expensive defaults for new small roasters. Curobi deserves a direct competitive test, but its conflicting access documentation prevents an unconditional integration recommendation.
3. A deliberately narrow owned engine is a serious option if subscriptions are the core paid product. Shopify supplies checkout, vaulting, contracts and charging APIs; its reference app supplies considerable application scaffolding. Fixed-SKU replenishment and one merchant-selected physical coffee per club cycle are a bounded product. The remaining work is concrete reliability, inventory, communications and management work, rather than building a payments platform from scratch.

Recommendation, conditional on evidence: use route 1 to test the connected selling experience with existing subscribers. For a subscription-led $99 single-app offer to new roasters, compare route 2 with Seal/Appstle against route 3 before choosing architecture. Advance the narrow engine if its distinct coffee workflow wins paid commitments and the reference-app audit plus lifecycle tests fit the team's capacity. Choose the provider route if it delivers the same promise economically with less ongoing work. Do not turn the lower initial engineering cost of an overlay into a claim of superior merchant economics.

Confidence: high on the documented platform boundary and observed price gates; medium on provider suitability; low on willingness to pay and delivery cost until a development-store test and merchant task comparison exist.

Boundary for the study website and wireframes

The concept may demonstrate coffee discovery and enrollment into existing eligible selling plans, with the current provider retaining billing and customer management. Describe provider names as research candidates, not working Coffee Kit integrations. Show automated physical-lot rotation as proposed, with two evaluated delivery routes: authorized provider API or a narrow Coffee Kit-owned engine. Neither route has passed an integration test. The website can explain this decision without presenting unfinished automation as live functionality. The three options should remain visible; do not silently commit the commercial offer to a provider overlay.

2. Evidence provenance and current market fit

Read before this work: the original user idea brief; current Coffee Kit and Krown direction briefs; existing data-discovery-evidence.md, economics-validation.md and checkpoint. The prior thread [research session] was read with includeOutputs:true. Its available response was truncated and recovered the Curobi pricing/API contradiction and Appstle partner lead, rather than a complete earlier research transcript. Current public pages were checked to close those specific gaps. The subscription agent ID in the old checkpoint resolves to this resumed work, so it is not an independent second source.

Labels below:

• Documented: a primary source describes the capability or requirement; this is not a passed integration test.
• Vendor claim: a provider's product or pricing promise; no independent reliability or conversion result is inferred.
• Observed signal: local exported technology detection; not proof of current paid use.
• Proposal/scenario: Coffee Kit design, recommendation or arithmetic assumption.
• Unknown/conflict: public evidence does not establish the effective entitlement or behavior.

The user's latest v1.1 signal was independently matched to cohorts.roaster_active and cohorts.local_roaster_active in verified aggregates (local handoff artifact). The active roaster-language cohort contains 5,990 entities; the Local + roaster-language cohort contains 94. These are screening cohorts, not 5,990 qualified subscription customers or 94 confirmed customers Krown can contact.

The final market report uses the narrower strong coffee AND roaster-language cohort, coffee_roaster_active, n=5,820. Its detections are Recharge 934, Seal 892, Appstle 714, Shopify 436, Loop 81, Skio 12. The strongest changing-catalog screening intersection contains 1,073 entities with strong coffee + roaster language, positive products_created_30, and a mapped subscription provider. Product creation is a proxy; it does not prove seasonal coffee rotation. Local + strong coffee + roaster contains 88, with Recharge 15, Seal 12, Appstle 12, Shopify 10 and Loop 4. These are narrower filters, not revisions to the 5,990/94 counts above. Use 5,820/1,073 for the final market narrative. See market report and the same verified aggregates.

Detections overlap. A zero is absence of a detection in this cohort, not evidence of no installed users. No paid status, live subscription volume, adoption intent or provider reliability follows from these counts. See audit and limitations (local handoff artifact). Inference: prioritize Seal/Appstle/Recharge testing, rather than importing an enterprise DTC vendor ranking into this niche.

3. Coffee subscription models are different promises

Real merchant examples establish that these shopping models exist, not the software beneath them. Square Mile offers whole-bean subscription choices. Trade's gift subscription uses a recipient redemption and quiz flow. Neither source proves Coffee Kit demand, a particular provider install or a sales uplift.

4. Shopify infrastructure versus app responsibility

Documented: storefronts can submit a variant plus selling plan to the cart; Shopify handles checkout pricing, consent, vaulted payment details and initial contract creation. The app maintains contracts, supplies management interfaces and automates renewals. Editing the original plan does not rewrite existing contracts. Shopify responsibility model.

The public SubscriptionContract reference requires read_own_subscription_contracts or write_own_subscription_contracts and exposes the managing app. These own-contract scopes are not a universal cross-provider write permission. Merchant OAuth access to products/orders does not itself confer contract ownership. A provider-issued key authorizes that provider's surface; it does not transfer the contract to Coffee Kit. An exceptional/read-all scope appearing elsewhere in Shopify's schema is insufficient evidence of general third-party entitlement.

Practical boundary: route 1 needs no provider Admin API for a plain, eligible Shopify selling-plan cart flow. Provider-specific bundle metadata, purchase widgets, tracking and customer portal actions still need a compatibility audit. Route 2 needs the provider's working write endpoints and commercial permission. No documented general API for external administration of the free Shopify Subscriptions app was established here; treat its setup and existing-contract editing as a merchant workflow until proven otherwise.

Current free Shopify Subscriptions control

Shopify now documents weekly/monthly/yearly plans with specific billing weekdays/dates and automatic expiry after 2–1,000 orders. The initial order counts, skipped orders do not, and the final order expires the customer's contract while leaving the plan available to new buyers. This is stronger than an assertion that native supports only signup-relative replenishment. Fixed billing dates do not establish a custom roast cutoff, and finite orders do not establish prepaid gift redemption. Current plan setup.

The free app also documents configurable payment/inventory retries and skip/pause/cancel outcomes, plus customer self-management. Those are real baseline features, not automatic Coffee Kit differentiation. Native settings.

October 2026 contract-editing correction

The SubscriptionContractCalculation flow is available in 2026-10, now stable as of this research date. It replaces stateful draft editing with calculate → asynchronous result/poll or webhook → commit, using the unified checkout engine. Legacy draft APIs coexist but are deprecated for this direction. Status-only actions remain separate. An early-access announcement written before October should not be read as saying the API is still an RC in November. Dated Shopify announcement.

The current migration guide describes four calculate operations plus commit, rather than freezing the early announcement's count at three. More significant: omitted top-level update fields can be preserved, but a supplied lines array replaces the entire stored list and each retained line must be fully restated. A rotation job must re-read/reconcile current state rather than send one changed line and accidentally remove the others. Cart transforms and delivery customizations are supported; the guide does not promise every Function type. Migration rules.

Bundles: surface-specific evidence conflict

The new API explicitly supports bundle contract edits from 2026-10, including grouped parent/component lines. Rebuilding from current merchandise definitions and preserving a stored bundle are different modes; deleted components/parents have specific consequences. Bundle contract-edit guide.

However, current merchant documentation still says bundles are incompatible with purchase options and the Shopify Subscriptions app; Shopify Bundles also lacks mix-and-match. Merchant bundle restrictions. The general developer bundle overview also retains a selling-plan limitation.

Conclusion: neither “Shopify can never do subscription bundles” nor “all bundle apps now work with subscriptions” is defensible. Contract-edit capability is verified; initial checkout, bundle representation, relevant enablement, provider adoption and renewal fulfillment must be proven for the exact combination. A box represented as several subscription lines, a permanent box SKU, and a native bundle parent/components product are separate designs.

5. Providers, prices and explicit API gates

USD advertised recurring prices observed 12 November. Provider percentage charges are additional to applicable payment processing/Shopify charges. Contractual, legacy and negotiated plans may differ. “API documented” is not a successful credential test.

Primary price/access sources: Seal matrix, Seal Merchant API; Appstle listing, direct API guide, partner framework; Recharge pricing, Recharge API/token access; Loop pricing; Skio pricing, Skio API use/testing, technical partner guide; Curobi current pricing, older pricing docs, older API entitlement; Kitenzo current pricing, developer access.

Specific evidence that changes the shortlist

Seal: its documented REST editing accepts a replacement variant ID, quantity and price for a subscription item. This is the essential primitive for a controlled coffee swap. Its rate limit is 10 concurrent requests per key, returning 503 when exceeded, not an assumed 10 requests/second. Public docs do not establish transaction locks against its renewal scheduler. A working endpoint is necessary but insufficient to guarantee an atomic pre-renewal swap. API reference.

Appstle: partner onboarding documents scoped per-merchant tokens, revocation on disconnect/uninstall, approved read-write access to status, skip/reschedule, discounts and line editing. It explicitly says merchants are not billed for partner API usage. This is stronger evidence than an anecdotal API surcharge, but Coffee Kit has no approved partner access yet. Direct API pricing and any developer-side commercial contract remain unknown. Partner integration. The API overview distinguishes customer-session Storefront APIs from API-key server access; they are not interchangeable.

Recharge: automatic monthly swaps already serve curated monthly programs, with monthly-frequency constraints; one-off and sequential workflows differ. Coffee-specific rotation alone is therefore not a unique Coffee Kit feature. Documented swap workflows. Compare preparing the next lot in Recharge against preparing it in Coffee Kit, including stock and merchant time, rather than merely comparing storefront screenshots.

Curobi: its coffee page claims rotating curated programs and build-a-box. API docs also state that contract line/status writes exist while plan/bundle definition write scopes are vocabulary without working endpoints. Even if all-tier access is effective, Coffee Kit cannot assume it can configure the whole provider backend through API. Documented API surface. This is competitive evidence, not established reliability or traction.

Kitenzo: older support pricing says $299/month + 1%, conflicting with the current 1.5%-only offer; use the current commercial page for scenarios and verify the installed contract. Dated older price. Its May subscription guide modifies the add-to-cart payload to include a selling plan from a separate app and recommends Single-SKU bundles while describing limitations. That is a purchase integration, not proof of component-aware recurring fulfillment after October's API changes. Subscription template guide.

6. Merchant economics across the three routes

Scenario, not forecast: $99 Coffee Kit fee, $30 subscription order value, one successful monthly order per subscription, no one-time items in those orders. Three cases: 100 orders/$3,000 revenue; 500/$15,000; 2,000/$60,000. Ignore tax, payment processing, Shopify plan fees, email/loyalty extras, discounts and implementation services here because they require merchant-specific inputs. Use actual invoices and fee bases in a pilot. Amounts are a normalized billing-period comparison; 30-day provider billing is not exactly a calendar month.

*Conservative feature budget because native product swaps appear on Premium; an approved API implementation may need a lower tier, but the evidence does not establish permission to bypass plan-gated features. Partner usage fee bypass is documented; partner acceptance and other commercial terms are unverified.

**Illustrative Starter pricing, not confirmation that the intended workflow is entitled there. Plus bundles at $15,000/500 orders would cost $499 + $201 + $95 = $795 provider-only, or $894 with Coffee Kit, before other charges.

***Merchant price hypothesis. Coffee Kit bears development, infrastructure and support cost; there is no free internal engine operation implied.

Seal scenarios assume total subscription count equals the shown count, with no additional cancelled/paused records consuming the cap. All routes have different feature coverage; the $99 native row cannot be sold as an automated rotating club. Scenario generator (local handoff artifact) and 24 computed cases preserve formulas and qualifications.

What these numbers support

At $3,000 recurring revenue, the proposed $99 alone is 3.3% of recurring revenue. Seal + Coffee Kit is about 3.5%; Loop Pro + Coffee Kit is 17.35%; Skio + Coffee Kit is about 24.93%. Revenue percentages do not equal profit percentages. A $99 overlay that requires a small roaster to buy Loop Pro or Skio is a weak default offer. It needs substantial, observed value beyond subscription selection and ordinary swaps. At $15,000, adding Kitenzo's 1.5% for another builder would add $225 to the relevant stack if all that revenue is billable bundle sales; its fee basis for renewals needs confirmation.

For an existing provider merchant, distinguish total stack cost from incremental adoption cost. If they already pay for an entitled API plan, the incremental fee may be $99. If the integration requires upgrading Loop Starter to Pro, the fixed uplift is $300 plus Coffee Kit, partly offset by the lower percentage: $399 − 0.25% × eligible subscription revenue, before other differences. At $15,000, that is $361.50 incremental; it cannot be described as a $99 upgrade.

Using the companion economics note's illustrative $18 contribution per genuinely incremental order: $99 requires six additional orders; a $361.50 incremental upgrade requires 21. Alternatively, at an assumed $30/hour, those amounts require 3.3 and 12.05 hours of useful saved work per billing period. These are thresholds for merchant evidence, not promised conversion uplift. Do not charge the overlay's value case for provider spend the merchant would already incur; also do not hide provider upgrades caused by Coffee Kit.

The strongest contradiction to an engine-first cost argument is Seal, not Skio. Replacing a $5.95–$24.95 engine creates little fee-saving justification for our own engine. Owning one must improve the single-app workflow, coffee-specific controls or supported outcome enough to pay for its maintenance. Conversely, a new roaster that would otherwise need a $399 API tier has a credible single-vendor cost reason to consider a narrow Coffee Kit engine.

Coffee Kit's internal owned-engine sensitivity

Budget scenario only, not an estimate from a completed build: 240 incremental engineering hours at $60/hour = $14,400; amortize over 24 months = $600/month. Ongoing maintenance 16 hours/month at $60 = $960/month. Add per store $3 incremental infrastructure/email and 10 minutes incremental support at $30/hour = $5. Incremental engine burden = $1,560 / engine stores + $8 per store/month.

This excludes the existing catalog/showcase app's costs and acquisition; cash salary and allocated labor must not be counted twice. Maintenance of 32 rather than 16 hours adds $19.20/store at 50 stores. The table shows why cheap merchant pricing and lean-team operability are different questions. Replace 240/16 with measured spike/on-call/support results before an investment commitment.

7. A deliberately narrow owned engine: bounded specification

What Shopify's reference app actually removes

Shopify publishes a subscriptions reference app including basic merchant and customer functionality; it is explicitly a starting point, and an App Store submission must add substantive merchant value. Public core component documentation describes hourly billing jobs, bulk charging, failed-payment recovery, persistence and inventory-error handling. It would be inaccurate to budget all of these as inventions Coffee Kit must design from zero.

A read-only source inspection pinned to 575a825f9f38aca9b0a1880e0fac10121b572a1c found:

Official docs additionally identify an unauthenticated-by-default internal job endpoint and tell developers to secure it. This is a specific production task. The source was inspected, not installed or exercised; no statement above proves renewal reliability. Production responsibilities in core guide.

Minimum useful owned scope — proposal

Support one domestic shipping market/currency, an explicitly verified payment gateway, pay-per-delivery plans, a small fixed set of weekly/monthly cadences, fixed-SKU replenishment, and a roaster's-choice club with one physical coffee variant and quantity per renewal. Preserve customer-selected bag size/grind, charge the disclosed club price, and require the merchant to publish each cycle's selection before billing. Offer pause, skip, cancel, address/card update and basic merchant exception handling. New clubs/customers first; no automatic migration of existing provider contracts.

Defer prepaid gifting, multi-coffee build-a-box, customer-editable monthly selections, variable-price substitutions, wholesale terms, custom roast cutoffs, POS enrollment, pickup scheduling and international billing. These are explicit product boundaries rather than claims Shopify cannot support them. Product/bag information and cancellation remain understandable without the founder operating the interface.

Owning subscriptions requires requested access and protected-data handling. Shopify documents the reference app's scope approval path; existing Krown app access does not prove approval for Coffee Kit. Reference app setup requirements. Scope approval is an external gate, not a reason to call the engineering intrinsically impossible.

8. Physical coffee rotation and inventory correctness

Design invariant: the coffee promised for a specific renewal must correspond to the physical Shopify variant(s) on its resulting order. A permanent “Roaster's Choice” SKU plus a text property naming this month's Ethiopia does not by itself decrement Ethiopia's physical stock. Renaming one SKU every month also destroys useful lot identity and does not explain old orders.

Two honest representations:

• Physical variant on the contract/order. Preserve club identity/rules separately; before the next charge, set the actual current lot's matching bag/grind variant and agreed price. This is the preferred narrow-engine design because stock and fulfillment use actual merchandise. The enrollment UI can describe the club while explicitly naming the first coffee. Verify plan eligibility and product visibility for each variant.
• Permanent club SKU with a fulfillment allocation system. Keep subscription merchandise stable, but explicitly reserve/decrement the physical lots through an integration or audited allocation workflow. This introduces a second stock ledger or operations system. Exclude it from a claim that a simple club SKU alone solves stock.

Shopify checks variant availability during billing and can fail for insufficient stock/location issues. Billing APIs also support an inventory policy override; use an explicit policy rather than assuming the merchant's “continue selling” switch always prevents overselling. Billing/stock behavior, inventory policy argument. The native app's “create order” override can oversell; exception handling should not silently select that behavior. Native inventory exception UI.

Proposed rotation sequence: merchant approves lot → validate each required size/grind mapping and price → identify affected unbilled cycles → reconcile concurrent customer edits → calculate and commit the chosen physical line(s) → verify persisted variant/quantity/price → permit that cycle's billing → link resulting order and stock outcome to the approved rotation record. Missing mapping/stock becomes a visible hold/skip decision, not an invented replacement. Freeze the selection for a retry of the same cycle unless an explicit reviewed change occurs.

In a provider overlay, the provider owns charging timing. “Swap an hour before midnight” is not a proven synchronization mechanism. The required evidence is a supported hold/cutoff/pre-charge flow, or another documented schedule that can guarantee the edit completes before billing, plus read-back and exception reconciliation. This is a key provider acceptance gate. In an owned engine, control of the charge queue makes this barrier easier to express, while Coffee Kit also owns recovery if the queue stops.

9. Twelve lifecycle edge cases and acceptance evidence

These are proposed development-store acceptance cases, not passed tests. Route 1 delegates provider lifecycle behavior and must explain that boundary; routes 2/3 must prove the promised orchestration.

Shopify supplies billing attempt states and idempotency primitives, so case 4 is not an unsolved payments invention. Billing attempt object. Its documented error taxonomy includes inventory, payment-method and buyer-action failures; those should drive distinct actions. Error codes. Provider credentials or payment-token migrations are a separate coordinated process, not a CSV-copy guarantee. Shopify payment-method migration.

10. Reviewable next decision, without implementation or outreach

Proposed evaluation uses the same merchant coffee, price, stock constraint and second-cycle task across routes. Measure merchant configuration minutes, correct physical order/stock outcome, exception recovery, support minutes and combined recurring spend. Use a stable blend as the control and a real expiring lot as the differentiating task. No conversion lift should be claimed from a small qualitative study.

Commercial gate: show qualified merchants the actual combined bill and supported scope. A $99 Coffee Kit + $24.95 Seal workflow is a different offer from $99 Coffee Kit + $399 Loop API, and a new $99 Coffee Kit engine competes with a free native app and inexpensive Seal. Require observed saved work or credible incremental contribution over that specific baseline. If the full kit cannot justify the extra fee, lower/repackage the offer or keep purchase components with the theme; do not hide a weak value case behind an integration strategy.

This report completes the public-evidence comparison. Effective provider credentials, production reliability, payment-gateway/market behavior, merchant willingness to pay and actual engineering cost remain unverified. No merchant access or outreach was needed to establish the documented gates and prepare the next test.

11. Migration addendum: a replacement-worthy coffee selling solution

Added 12 November 2026 following the founder's clarification. “The #1 solution for selling coffee on Shopify” is an ambition, not a verified ranking. Existing providers are potential displacement targets, not permanent dependencies. The defensible proposition is one better coffee-selling workflow: reviewed catalog → discovery → enrollment → physical-lot renewal → customer management, with assisted switching. Purchase-only UX can validate entry, but an owned engine earns replacement status through that complete outcome. Neither inexpensive billing nor migration alone is a durable moat.

Ownership, portability and customer authorization

Documented: the subscription agreement is between merchant and customer; Shopify stores the contract and identifies its owning app, whose scopes govern administration. A provider API key grants provider access; it does not transfer Shopify ownership. Selling-plan changes do not rewrite existing contracts. No universal third-party reassignment mechanism was established here: budget supported recreation/import into destination-owned contracts, preserving source-to-destination IDs. Contract model, responsibility model.

Payment methods are a separate layer: Shopify-vaulted customer payment-method IDs versus legacy processor-held tokens. Neither is a portable plaintext card export; provider API credentials are also separate secrets. Same-store migrations may reuse valid Shopify payment methods, but retain the exact method associated with each contract: Recharge warns that omitting its ID can select another saved method. Recharge migration requirements.

Shopify documents token migration on all plans with subscription-developer support; raw card-number migration uses paid Professional Services and requires Plus/Enterprise. Legacy secondary-gateway removal and cross-store moves need separate assessment. Changed PayPal accounts can require customer reauthorization because billing agreements belong to the originating account. Do not promise universal “no reconsent.” Where a valid authorization can be preserved, migration need not mean fresh enrollment; otherwise provide the supported payment-update/reauthorization flow, or fresh checkout where necessary. Preserve agreed terms; any proposed price, cadence or substitution change needs a separate customer-authorization assessment. Shopify payment migration and limitations.

Supported migration versus a file export

Official paths exist: Shopify Subscriptions offers contract CSV import/export; Appstle documents validation and paused destination imports; Seal documents CSV/manual recreation and conditional Recharge/Bold API migration in its manual. These establish feasibility, not a supported migration into Coffee Kit, whose importer and payment-access path remain unbuilt. Export/import does not automatically preserve payment authorization, schedules, prepaid liabilities, portal links, loyalty or analytics history. Recharge explicitly excludes historical/analytics data from its migration process. Recharge coverage.

Proposed rehearsal, cutover and rollback

1. Scope: one source app/store/gateway/currency; classify vaulted versus legacy methods, supported products, paused/cancelled states, discounts, next dates and outstanding paid shipments. Agree exceptions and retain exports, source IDs and an audit ledger.
2. Rehearse: validate mappings and totals with synthetic/redacted data; destination remains unable to charge. Separately verify authorized payment-method access. Reconcile every contract's merchandise, grind/size, price, shipping, status and next billing date. A CSV passing syntax validation is insufficient.
3. Cut over: take a final delta; freeze source edits; stop source billing/retries and reconcile in-flight attempts before activating each destination cohort. Switch storefront plans and portal links. Assign exactly one billing authority per contract/cycle; maintain idempotency and success/order reconciliation. Appstle's paused-import sequence supplies a documented precedent, not a tested Coffee Kit guarantee.
4. Observe: monitor the first renewal cycle and exceptions; retain the old app, securely restricted and unable to bill, while rollback remains necessary. Shopify cancels surviving app-owned contracts 48 hours after uninstall; uninstall is not a reversible pause. Recharge separately warns processing continues until cancellation. Verify the actual source stopping mechanism. Shopify lifecycle, Recharge exit procedure.
5. Rollback/refunds: stop destination billing, reconcile completed charges/orders, then resume only unpaid cycles in the source if its contracts/credentials remain usable. After cancellation/uninstall, restoration may require recreation and provider help. Refund duplicate charges through the original order/payment route; separately resolve duplicate fulfillment. Handle refunds and future-contract cancellation as separate actions. Migration rollback cannot erase completed payment events.

Sales, AI and technical responsibility

Sales can qualify workflow fit, compare actual invoices, collect scoped access approvals, demonstrate the replacement, coordinate timing and explain changed customer links. AI can draft field mappings, flag anomalies, compare redacted snapshots and prepare merchant/customer instructions. Deterministic validation and technical review decide correctness. Keep payment credentials/card data out of ordinary AI prompts.

Engineers/providers retain payment-access verification, gateway coordination, importer correctness, status/billing synchronization, exception handling and rollback execution. The merchant authorizes the switch and communications; customers complete any required reauthorization. AI assistance reduces preparation work; it does not establish authorization or guarantee payment portability.

Fixed-scope service economics — assumptions

Test $750 one-time, separately from $99/month, for up to 500 simple pay-per-delivery contracts, one supported source/store/gateway/currency, one rehearsal and cutover, and first-cycle monitoring. Exclude prepaid/gifts, processor changes, bespoke bundles, historical analytics reconstruction and provider fees.

Illustrative cost: sales coordination 2h × $30 = $60; technical work 3h × $60 = $180; support/monitoring 2h × $30 = $60; tooling $20; contingency $100: $420, leaving $330/44% contribution before acquisition and fixed overhead. Five extra technical hours consume $300. Waiving the fee subsidizes $420 of delivery, or $70/month over six months before recurring costs. Measure actual hours and quote exceptions separately. Replacement should win on the ongoing coffee workflow; assisted migration makes that choice attainable. No migration or outreach was performed.

Source: subscriptions-evidence.md The complete Markdown handoff and private datasets remain in the local project. This web edition includes selected supporting visuals and scenario downloads.