Child note of ideas/jpeg-region-scrambling. Covers the business/product direction if the server-offloaded decrypt (see parent, "Delivery: Browser Extension") is extended into a service people pay for — "interesting if it took off", not yet committed to.
Launch free — cheap/small server, no accounts, no billing — to validate demand before writing any monetization code. If it takes off, add a paid “fast lane”, modelled on free file-download sites: free tier is served by the small/cheap server (slow because it's under-provisioned, not because of queue logic); paying subscribers get redirected to a beefier (“XXL”) server/deployment for instant processing.
Revised 2026-08-30: the split can be a routing decision rather than an application-level queue — a single subscriber-flag check at request time, then a redirect (e.g. HTTP 302) to a different hostname/deployment. No queue implementation, no concurrency-limiting code, no artificial-delay tuning needed. Trade-off: dev-time for infra — running two deployments instead of one with internal logic — worth picking hosting where the XXL tier can scale to zero/near-zero when idle (serverless, or autoscaling with a floor of 0–1) so paid capacity isn't a fixed cost sitting idle between paying requests.
• Free beta: server-offload endpoint (≈ 1.5–2.5 days, see parent note's Delivery section) + lightweight queue with limited concurrency / rate-limiting to keep a cheap server from being overwhelmed (≈ 0.5 day).
• Free beta: server-offload endpoint (≈ 1.5–2.5 days, see parent note's Delivery section), running on an under-provisioned instance — no queue code needed, slowness comes from instance size alone.
• Paid fast lane, once worth building: Stripe subscription flag + redirect-on-check logic + provisioning the XXL deployment. No registry needed; saving vs the original queue-based estimate is more in complexity type (infra config vs application logic) than raw time, since billing integration was always the bulk of this.
Original framing, kept for reference — pay to unlock a specific image rather than pay for speed. Heavier: server owns an image→key registry and checks per-image entitlement before using the key.
• — Stripe Checkout + webhook + boolean "active subscriber" flag checked at unlock time.
• — viewer tops up (e.g. £5), each unlock debits a small amount. Addresses true per-unlock "tiny amount" card charges being uneconomical (processing fee can exceed the charge).
• — supports sub-cent charges but pulls in an unfamiliar payment rail; substantially more effort.
Effort: registry ≈ 0.5 day, subscription billing ≈ 1–2 days, extension paywall step ≈ 0.5–1 day — , on top of the server-offload baseline. Prepaid-credit adds ≈ 1 more day; Lightning adds substantially more.
Applies to either model: server-side gating controls access to processing, not what happens after — once a viewer has the unscrambled image on-screen, nothing technical stops saving/redistributing it. True of essentially all server-gated content, not specific to this design.
This is a real pivot from a personal-privacy tool to a small paid product: accounts, billing, and abuse/rate-limiting on the endpoint all become real surface area, distinct from the image-scrambling maths itself (which stays exactly as designed in the parent note).
Direction noted 2026-08-30 as potentially interesting if the core tool takes off. Not committed to — no work started. Free-beta-first is the current preferred sequencing; depends on the server-offload delivery approach in the parent note being built first. Deliberate principle: the paid-tier work (billing integration, XXL deployment, redirect logic) is not built, provisioned, or spent on at all until the free beta demonstrates actual demand — the effort estimates above are “cost if it takes off”, not committed work.