M12.5 (strategy, not engineering): MeedyaDL+ paid tier — launch / defer / skip decision

[Salem874]

Summary

Strategy issue, NOT engineering. This issue captures the open commercial decision on whether/when to launch MeedyaDL+ — a paid tier that gates the native-API cloud upload path (M12) behind a subscription, while leaving the rclone path (M11) and protocol-based path (M13) free for everyone.

The technical architecture (M11/M12/M13) is designed to support MeedyaDL+ without code disruption — a single feature_flags.meedyadl_plus_active boolean in AppSettings governs the dispatcher's premium-routing path. No code change is needed to launch or skip the paid tier; the question is purely whether to build the surrounding commercial infrastructure (licence keys, payment processor, billing support).

Parent epic: #858. Architecturally enabled by M11.

The decision

Option	What it means
A. Don't launch	Leave feature_flags.meedyadl_plus_active = true by default. All users get native API path. No paid tier infrastructure. MeedyaDL stays fully free.
B. Launch as low-touch tip-jar	GitHub Sponsors / Patreon donation tier. No licence-key enforcement; honour-system. Donations fund maintenance but everyone gets full functionality.
C. Launch as proper paid tier	Stripe / Paddle / Lemon Squeezy integration. Licence keys. Default flag to false, set to true on licence verification. Free users fall back to rclone path.

The rationale for considering a paid tier (in case future readers wonder why)

Two motivations, in order of strength:

1. Demand-shaping for a quota-constrained resource (the strong argument)

When cloud upload is free and one-click, a meaningful fraction of users enable it "because they can" without genuine need — "I might as well back up to Dropbox while I'm at it." Those users have plenty of local disk and don't really benefit, but they consume API quota that someone with genuine need (256GB MacBook archiving a 600GB discography) actually requires.

Pricing creates a self-selection filter: users willing to pay £3-5/mo are users for whom the value exceeds the cost — i.e., they have a genuine need. Casual users self-select OUT of the paid tier and use rclone instead, which uses rclone's own quota pool, not MeedyaDL's. Net effect: MeedyaDL's reserved API quota is preserved for users who genuinely need predictable cloud upload performance.

This is a textbook tragedy-of-the-commons protection, not pure revenue extraction.

2. Sustainability revenue (the secondary argument)

OAuth approval / provider review / API key rotation / customer support — these are ongoing labour costs. A paid tier provides revenue to fund them. Industry precedent: GoodSync, Carbon Copy Cloner, Insync, ExpanDrive, Mountain Duck — all the comparable consumer cloud-sync tools have free + paid tiers, exactly for these reasons.

The rationale for NOT launching (or delaying)

• MeedyaDL has always been free / MIT. Introducing a paid tier is a brand shift.
• The audience is FOSS-aligned. GAMDL users skew technical and ideologically prefer free tools.
• Launch infrastructure complexity. Stripe / Paddle / VAT (EU) / refund policies / dispute handling / licence-key security / piracy mitigation — entirely new infrastructure stack.
• Quota concern is hypothetical until proven. We may never hit global API quotas. Premature monetisation could be solving a problem that doesn't exist.
• rclone is free and exists. Users who can't pay just use rclone. We don't gain much revenue while losing perceived openness.

What this issue is NOT

• This is not a decision to launch MeedyaDL+. It's a placeholder for the decision.
• This is not an engineering ticket. M11 ships the feature_flags.meedyadl_plus_active boolean (defaulted true) with zero user-visible effect; this issue covers the business decision on whether to flip that default.
• This is not time-bound. The flag can sit at true indefinitely while we ship M11/M12/M13 and watch usage patterns. Decide later (or never).

Decision-relevant signals to watch

Before making the call, useful data to collect over the M11 → M12 → M13 shipping window:

• Adoption rate of cloud upload. % of MeedyaDL users who configure ANY cloud destination. <5% → probably skip paid tier (not enough demand to bother with billing). >20% → consider paid tier.
• Quota pressure. Do we approach Google/Microsoft/Dropbox global rate limits? If never close, demand-shaping argument weakens. If we hit them often, paid tier becomes a real necessity.
• Provider review outcomes. If Dropbox / Box reject our production review, we may be forced into bring-your-own-credentials mode anyway — different conversation.
• User feedback / requests. Are users asking for premium support? For priority quota? Or are they happy with the free rclone path?
• Maintenance cost. Track our own time on cloud-feature support / OAuth rotation / quota management. Above ~5 hr/month is when a paid tier starts paying for itself.

If we do launch (Option C) — minimum viable launch checklist

Recorded here so we don't reinvent the wheel later:

• Payment processor — Paddle (merchant of record, handles VAT/tax) or Stripe (more flexible, we handle tax). Paddle preferred for EU compliance.
• Licence-key system — JWT-based with signed expiry, stored locally. Anti-tamper via signature verification against an embedded public key. Acceptable that determined attackers can crack it — anti-piracy is cat-and-mouse, focus on honest users.
• Licence verification endpoint — Cloudflare Worker (extends our existing update.mwbm.io infrastructure pattern) at e.g. licence.mwbm.io/verify. Receives licence key, returns signed entitlement JSON. Short TTL so revocations propagate.
• Account portal — User dashboard for managing their licence, seeing payment history, requesting refunds. Could be off-the-shelf via Paddle's portal.
• Pricing strategy — initial: £3/mo or £30/yr or £79 lifetime. Adjust based on conversion data.
• Refund policy — published, honoured. 14-day no-questions-asked for EU compliance.
• Support channel — email or Discord for paid users with reasonable SLA expectations.
• Privacy policy / terms of service — required for taking payments.
• MeedyaDL+ marketing copy — landing page, comparison table (Free vs +), FAQ. Ideally lives at e.g. meedyadl.com/plus.

This is a 4-8 week effort if pursued. Not trivial. Worth doing only if signals justify it.

If we DON'T launch (Option A)

• Leave the flag at true forever
• Native API destinations remain functionally free for all users
• API quotas managed via pre-emptive throttling + best-effort backoff
• Revisit if quota pressure becomes a real problem

Worst-case-realistic outcome: at some point Google Drive's app-global quota hits a busy day, paying-quota separation would have helped, we accept the temporary user disruption and revisit.

Related

• Parent epic: #858
• M11 (foundation, includes the feature flag): #TBD
• M12 (native API integrations the flag governs): #TBD
• M13 (protocol-based, not gated): #TBD
• update.mwbm.io infrastructure (similar pattern for licence verification): MWBMPartners/MeedyaDL#856

Definition of done (for this strategy issue)

• Either: explicit decision-to-launch with concrete Stripe/Paddle integration milestone + commercial-launch sub-issues, OR
• Explicit decision-to-defer with revisit-date noted (e.g., "revisit Q3 2027 if adoption signals shift"), OR
• Explicit decision-to-skip-permanently with this issue closed and the feature flag's default cemented at true

[Salem874]

---

Cross-link tracker (added 2026-05-22):

• Parent epic: EPIC: Direct-to-cloud upload (rclone + native APIs) — disk-bound users + cloud-first workflows #858 — EPIC: Direct-to-cloud upload (rclone + native APIs)
• M11 (foundation + rclone + UploadPending state): M11: rclone foundation + CloudDestination trait + UploadPending queue state (Cloud upload milestone 1) #859
• M12 (native API: Google/Microsoft/Dropbox/Box/Mega): M12: Native API integrations — Google Drive + Microsoft + Dropbox + Box + Mega (Cloud upload milestone 2) #860
• M13 (WebDAV + S3 + SFTP protocol clients): M13: WebDAV + S3-compatible + SFTP native protocol clients (Cloud upload milestone 3) #861
• M12.5 (MeedyaDL+ commercial decision — strategy, no code): M12.5 (strategy, not engineering): MeedyaDL+ paid tier — launch / defer / skip decision #862
• Tools-side packaging (rclone in MeedyaDL-Tools mirror): Add rclone to mirror packaging — needed for MeedyaDL cloud-destinations feature MeedyaSuite/MeedyaDL-Tools#17

Closing one does not close the others — milestones ship independently.

[Salem874]

📋 Status — 2026-05-25 (cloud-upload EPIC audit)

Walking through in the open-issue audit pass. No work has been done on this milestone yet, but flagging current project state so the issue's scope is anchored to today's foundation.

Foundation already in place

• rclone is wired as an optional external tool in tool-versions.toml + dependency_manager.rs (per chore: rationalise alpha/main drift — forward-port rclone + multi-endpoint updater + bug fixes (closes #873) #877). Not auto-installed; pulls down on demand when a Cloud Destination is enabled.
• engines.toml + engine_registry.rs define the multi-service download-engine abstraction. Cloud destinations will sit alongside this rather than reusing it.

What's NOT yet in place

• No CloudDestination trait, no UploadPending queue state, no native API integrations (Google Drive / OneDrive / Dropbox / Box / Mega), no WebDAV / S3 / SFTP clients.

Cross-link to current branch work

The branch feat/871-library-enrichment-skip (still unmerged, awaiting PR instruction) lands:

• EPIC: SQLite-backed download index + activity log (dedupe + gap-fill + multi-service foundation) #875 EPIC A (SQLite download index) — feature-complete (M1-M5). The DB schema includes downloads.file_path + downloads.file_sha256 which the cloud-upload work will eventually consume to dedupe uploaded vs local copies.
• EPIC: Profile export/import bundle (.meedyabundle — device-to-device portability) #876 EPIC B (.meedyabundle profile export/import) — feature-complete (P1-P6). Bundle format includes an OPTIONAL Database section + encrypted credentials, so the eventual cross-device portability needs are covered.

Both EPICs land foundation that the cloud-upload work will sit on top of. M11-M13 scheduling has not changed — still post-RC, no calendar commitment yet.

Leaving the issue open at its original scope. No action needed from the maintainer; this comment is a snapshot for traceability.