# Profectus — Monetization Record Running file for all monetization discussions and ideas. Companion to `profectus-public-launch-roadmap.md`. Decisions get moved from "Open" to "Decided" only by explicit agreement. ## Decided - 2026-10-05: DONATION/OSS MODEL ADOPTED. App code published open source on GitHub (brand handle, never personal identity); donations via GitHub Sponsors / Ko-fi / Liberapay as the public monetization face. Supersedes the "Pro ~39 CHF one-time feature license" pricing proposal (kept on record below as fallback only). No feature paywalls, no license keys, no Paddle product approval needed. - 2026-10-05: PAID MANAGED SYNC ALLOWED (reframes the old "gating sync = trust killer" rejection): we never sell access to user DATA or app FEATURES; we sell the convenience of running the server. Guardrails: server URL configurable in-app (default ours, any instance accepted), local mode + folder backups + self-hosting stay fully free, export-everything always free, zero features gated, no lock-in on cancellation. Subscription shape ~15-25 CHF/yr via MoR (Paddle). Purchase on profectus.fit only — no Google Play Billing in the F-Droid build; entitlement flips server-side. F-Droid policy verified clean (server FOSS + self-hostable + URL-configurable avoids NonFreeNet/TetheredNet). - 2026-10-05: HOSTING SPLIT: GitHub = free face (repo, README/docs, issues, donations, links to hosted service; NOT the runnable app or checkout once paid sync exists — GitHub ToS bar SaaS/commerce hosting). VPS (Hetzner CX22) = runs sync server + serves the PWA + landing (needed regardless for sync; marginal cost ~0). - 2026-10-05: LICENSE = AGPL-3.0 for the whole repo (client + server). Protects the paid-sync model (network clause closes the closed-SaaS-fork loophole). Stores unaffected: Play/F-Droid fine; iOS later as owner-distributor (copyright holder may ship own work under Apple's terms). No CLA while only the owner contributes; dual-licensing only if a partner ever demands it. ## Principles (agreed) - The app must remain free and local-first forever; the data is the user's, export-everything free, no feature paywalls. paid monetization sells only services/convenience, never data or features. 1. Core web service stays free permanently; monetization sells convenience, not access to users' own data or history. 2. "Support the founder" framing; no ads, ever; no dark patterns. 3. Anonymous registration must remain possible for payers (license-key entitlement, no email required). ## Idea bank (ranked 2026-10-05) **Strong** - Analytics & progress intelligence (volume charts, e1RM, muscle-group workload, plateau detection) — Pro - Export & reports (CSV, PDF progress report, backup file) — Pro - Program slots: free = 3 concurrent programs, Pro = unlimited **Weaker / optional** - Warm-up circuit customization, personalization extras — Pro - Early access + supporter badge — Pro **Rejected** - Gating sync/cloud backup of user data (trust killer) - Gating the guide/articles core content (top-of-funnel marketing) - Ads (contradicts shipped "no annoying ads" promise) **Pricing proposal (open)** - One-time Pro ~39 CHF + optional yearly Supporter ~19 CHF/yr - License key issued by merchant-of-record (Paddle/Lemon Squeezy) or BTCPay; key entered in app = entitlement ## Discussion log ### 2026-10-05 — Paywalling features that were free at launch User's concern: shipping all features free at launch, then paywalling analytics later, makes early users feel robbed. Alternative: hold features back from initial launch, at the cost of a less attractive free product. Assistant view: the risk is real and the fix is sequencing + grandfathering: 1. Friends-and-family soft launch (small group) = everything free, fine. 2. Introduce the Pro tier BEFORE wide public launch, with a public roadmap ("analytics coming, will be part of Pro"). Nobody loses what they had; new users see the boundary from day one. 3. Grandfather early users: founder-member Pro free or steep lifetime discount. Converts the "robbery" into goodwill and testimonials. 4. What must never flip retroactively: anything affecting logging or access to existing data. Feature gates only for new, additive capabilities. Conclusion: holding analytics back from launch is acceptable and probably correct; the lost attraction is modest because the core method + articles sell the app. ### 2026-10-05 — Locking articles behind premium Assistant view: don't lock the existing corpus. Articles are the acquisition engine and the honesty backbone ("support the founder" rings hollow behind a content paywall). Acceptable variants: - Free: full existing + future standard articles. - Pro: genuinely NEW premium content layers (deep program guides, phase-by-phase write-ups, video technique library) — created as Pro from the start, never retro-locked. - Teaser pattern allowed: first paragraphs free, remainder marked Pro (standard, not resented). ### 2026-10-05 — Paid native app with free web Question: charge for a native app while web stays free? What would an app even add? Assistant view: - A paid-app model (web free, app paid) is awkward: app stores take 15-30% and Apple requires their IAP for digital features, cutting into the license-key model. - Better: free native app (Capacitor wrapper reusing the existing web codebase, cheap to maintain) with the SAME Pro license unlocking app-exclusive conveniences. - Native-only value: lock-screen rest timer with haptics, home-screen widgets (next workout, streak), push reminders (scheduled sessions), Apple Health / Health Connect sync, watch app for logging on the wrist, background audio cues. - Suggested split: app free with full core; Pro license unlocks the native conveniences (watch, widgets, Health sync). This makes "Pro" more tangible without ever touching web users' features. ### 2026-10-05 — Do we need a company? User: with low expected conversion and a cheap one-time price, running a dedicated company for this seems expensive. Is there a lighter form? Assistant view: no company needed at launch, and Switzerland has exactly the light form you'd want. Sequence: 1. **Private individual, no registration (start here):** selling digital products via a merchant-of-record (Paddle/Lemon Squeezy) requires no Swiss legal form — the MoR is the seller of record, handles worldwide VAT, and pays you out as a private person (individual/sole-trader payouts are supported). Your obligations: declare the income in your tax return; crypto proceeds likewise. Works fine while revenue is small. 2. **Sole proprietorship (Einzelunternehmen) — the "cheap business form" you were missing:** no minimum capital, registration in the commercial registry ~120 CHF and only *mandatory* once turnover exceeds 100k CHF/yr (or earlier if you want the trading name protected / invoice credibility). Liability is personal, but the risk profile here is trivial (no debts, no inventory, MoR holds the payment risk). AHV self-employment contributions apply on profit. 3. **GmbH — later, if ever:** since the 2023 reform only 20k CHF capital. Justified when revenue is real, you want liability separation, or the product gets a co-founder/partner. Not needed for a ~40 CHF one-time product. Net: start private via MoR + BTCPay, register an Einzelunternehmen only when turnover approaches 100k or the brand needs one, GmbH only if the business earns it. Expected annual overhead until then: ~0 (no accounting audit, no registered office, no annual fees). Caveats: single-member GmbH rules, and if the product ever interconnects with the asset-management track, formal separation becomes necessary — keep the tracks apart. ### 2026-10-05 — Must customers be able to find out the vendor's identity? Yes. As a Swiss private individual or sole proprietorship selling to consumers, identity disclosure is mandatory: - Swiss UWG (Unfair Competition Act, Art. 3, revised 2021): commercial communications must state the vendor's name and address; this applies as soon as you act commercially (regular paid sales), regardless of legal form. - GDPR (worldwide/EU launch): the privacy policy must name the controller with contact details. - Practical mitigation (legitimate): publish a postal point of contact rather than your home address — a PO box / c/o address or a cheap business-address service satisfies the requirement. What is NOT possible: a fully anonymous storefront. (Anonymous PAYMENT stays possible for customers — Mullvad model; anonymous VENDOR does not.) - Domain WHOIS privacy (registry level) can still hide personal data from casual lookups; that coexists with the on-site disclosure requirement. - The MoR's checkout will show their own entity as seller of record, but your site must still identify you as the product's controller/vendor. ### 2026-10-05 — Separating the founder's public identity from the content User's concern: normal career in finance; does not want spicy/controversial articles publicly associated with his name, and worries customers may pay less seeing the founder has another career. Assistant view: 1. The law requires disclosure in the LEGAL layer only (imprint, T&Cs, privacy policy). It does not require the editorial content to be signed with a legal name. 2. Legitimate structure: pen name / brand voice ("the Profectus team" or an invented pen name) for all articles and marketing; real identity confined to the legally required imprint + privacy-policy controller line. This is a standard, respected practice (many authors, newsletters and indie products do exactly this). 3. Line not to cross: inventing a fake human author with fake credentials or fake testimonials is deceptive marketing (misleading under UWG/Art. 3 and dishonest by the app's own standards). A transparent pen name is fine; a fabricated person is not. 4. Association-risk hygiene: domain WHOIS privacy, imprint uses a c/o address, register nothing under the real name that links the pen name to it, keep MoR payouts to a personal/bank channel that is not public. The realistic leak is the user's own cross-posting (same handle style, writing tics, photos) — decide the persona's boundaries once and keep them. 5. The "successful alternative career" worry: this is mostly a non-problem; but the pen-name structure solves it regardless, and later a GmbH can fully separate the commercial identity if the product grows. 6. No need to revise the spicy articles under this structure — the voice is the brand's, not his; keep the opinions. (If a piece ever feels too hot even for the brand, edit it as content, not as identity management.) ### 2026-10-05 — Cheapest imprint-address options (Swiss) Ranked by cost: 1. **Home address, 0 CHF.** The zero-cost default; most Swiss sole proprietors put it in the imprint. Exposure is one static webpage (name + street + town); fitness-audience harassment risk is negligible. Can be revisited anytime. 2. **c/o a friend or relative, 0 CHF.** Legal and common; someone must accept mail for you. Best cost/privacy ratio. 3. **Swiss Post Postfach, ~110-170 CHF/yr** (size-dependent) + ~40 CHF/yr if you want mail forwarding to home; free retail collection at the counter. Note: for court service (Rechtssicherung) a PO box alone can be insufficient, so the bulletproof version is still a physical address. 4. **Business-address/virtual-office services, ~20-60 CHF/mo.** Overkill at this stage; revisit for a GmbH. Recommendation: start with home address (0) or c/o (0); add a Postfach only if the site gets traction. Do not spend 240+ CHF/yr on a virtual office before the first paying user exists. ### 2026-10-05 — Payment-handler fee comparison (verified via official pages Sep 2026) **Paddle (MoR):** 5% + $0.50 per checkout transaction, all-inclusive (card processing, worldwide VAT/sales-tax handling and remittance, fraud, chargebacks, billing). No monthly, setup, or migration fees; no minimum volume. Products under ~$10 → custom pricing (contact them). Payouts: standard payouts free; ~$5 fee on some SWIFT/remote-currency routes. **Lemon Squeezy (MoR):** headline also 5% + $0.50, BUT docs add surcharges: +1.5% international transactions (we are non-US selling worldwide, so this always applies), +1.5% PayPal, +0.5% subscriptions; fee computed on order total INCLUDING tax. Effective ~7% + $0.50 for us. Payout: $50 minimum threshold, 1% payout fee on non-US bank, twice-monthly schedule. **Stripe direct (not MoR):** ~2.9-3.5% + 0.30, but you keep VAT/compliance liability yourself: EU consumer digital sales would need own OSS VAT registration once selling there, Swiss VAT only above 100k CHF. Cheaper per sale, heavier admin; the reason we chose MoR. **BTCPay (self-hosted):** 0% processor fees, no payout fees (self-custody wallet), no minimums. On-chain network fees normally paid by the buyer; Lightning ~free. Refunds at your discretion (no chargeback mechanism at all). **Worked example — 39 CHF Pro license, EU customer (VAT included in shelf price):** - MoR collects price incl. VAT; fee is on the gross. Paddle: 39.00 gross -> ~2.45 fee -> ~36.55 before VAT remittance; Paddle remits VAT (CH ~8.1% ≈ 2.92) -> net to you roughly ~33-34 CHF (~85% of sticker). - Key nuance: as MoR they are the seller, so VAT is THEIRS to remit, but it still comes out of the sticker price. Real takeaway: net ~80-85% of list price on EU sales. - BTCPay sale of the same license: ~39 CHF lands in your wallet minus your own Swiss VAT obligation bookkeeping (below 100k turnover: no Swiss VAT registration owed; EU VAT on digital services via MoR doesn't apply to crypto-direct sales — EU OSS registration would technically be required for B2C EU sales at scale; for small early volumes this is the same "private sale" exposure as before formalizing). **Recommendation:** Paddle over Lemon Squeezy (LSQ's international surcharge always hits us). Fee is the price of outsourced VAT/compliance; revisit Stripe-direct only if volume makes the admin worth it. Paddle requires product approval — apply early in Phase 3. ### 2026-10-05 — Sponsoring rest-pause YouTube channels (research + assessment) Benchmarks (2025-26 data): health/fitness sponsorship CPM $15-45 per 1000 views (median ~$32); a 60-90s integration on a channel averaging 20k views ≈ $300-900; dedicated video 2-4x that. Micro creators (10-100k subs) charge $50-500/video. App-download CPA via influencers: $3-20 for trial-based subscription apps, but discovery traffic converts worse; cost per PAID subscriber via influencer/creator channel runs $30-200 (adwave benchmark), bimodal (Airbridge: some creators convert, most produce vanity installs). Profectus-specific funnel estimate (one 20k-view integration, $500 fee): - 20k views → 1-3% CTR = 200-600 clicks → 40-150 installs → at indie-typical 1.5-4% paid conversion = **1-6 paying users** → **CPS $80-500** vs net LTV ~$36 (39 CHF one-time, post-fee). - Expected ROI: clearly negative on first purchase. Only works if LTV were subscription-scale ($150+) — it is not with a one-time 39 CHF product. - Attribution: our advantage is that Profectus is a web PWA — links survive (no app-store UTM stripping); a promo code + landing path suffices. Recommendation: 1. No flat-fee sponsorships before product-market fit. Bleak confirmed, with numbers. 2. Zero-upfront alternative: affiliate/revenue-share deals with rest-pause-adjacent micro creators (free Pro for them, unique codes, ~30-50% first-year rev share). Costs nothing unless it works; good fit because dedicated rest-pause channels are small (5-50k subs) and their audiences are exactly the niche. 3. If a flat test is ever run: one micro channel, <=300 CHF cap, unique link+code, 90-day attribution window, kill criterion CPS > 50 CHF. 4. Honest-review angle: send free Pro + founder-call offer; ask for a critical review, not an ad — fits the brand and small channels accept product-only deals. ### 2026-10-05 — Cost-effective distribution plan (post-launch) Ranked by expected yield per hour invested: 1. **Seed the inner circle first** (friends, gym partners, the people the method already worked for). Every early testimonial is later ammunition; ask 5-10 of them for one honest paragraph each. 2. **Community participation, not ads** (0 CHF): genuinely useful posts/comments in r/naturalbodybuilding, r/leangains, r/HypertrophyTraining, bodybuilding forums; answer rest-pause method questions; mention the app only when relevant + a weekly "we built this" post in appropriate self-promo rules. Failure mode to avoid: link-dropping = bans + brand damage. 3. **Long-tail SEO via the existing 28 articles** (0 CHF, slow): fitness head terms are unwinnable, but specific queries ("rest pause training program", "27 seconds rest partial reps", "rest-pause vs drop sets") are winnable and pre-qualified. Cost: keep publishing 1-2/month, 90-day lag before judging. 4. **Free interactive tools as linkbait** (build once): rest-pause calculator, partial-set percentage tool, TUT calculator. Rank for "rest pause calculator" type queries, funnel to the app. Highest ROI build item on this list. 5. **Short-form video, method-first** (0 CHF, high effort): 30-60s clips of the partial-set failure principle (a rep-10-11-12-to-failure demo) on TikTok/Reels/Shorts. Method content outperforms app-demo content; the app link lives in bio. 6. **Launch listings** (0 CHF, one afternoon): Product Hunt, Hacker News (Show HN if the privacy/anonymous angle is framed well), IndieHackers, r/SideProject, BetaList. Modest traffic, useful backlinks. 7. **Affiliate micro-creators** (rev-share only, see sponsorship note): zero upfront. 8. **Swiss angle later**: once imprint/company exists, local press (20 Minuten lifestyle? small) only if a story exists; not a priority. Kill/discipline rules: no paid acquisition at current LTV; judge each channel on activation (3+ workouts in week 1) and 30-day retention of acquired users, not raw signups; time-box community effort to ~3h/week. ### 2026-10-05 — Open source on GitHub + F-Droid + donations instead of a Pro license User's reasoning: the app is easy to replicate with AI anyway, no significant marketing planned (so no first-mover window to monetize), so why not publish the code, ship on F-Droid, and run a donate/coffee model like typical OSS projects. Assistant view: 1. The replicability premise is right but cuts in favor of open-sourcing: the code was never the moat. The moats are the method corpus (28 articles + guide), the community voice, trust, and a maintained hosted service. AI replication threatens those only partially (corpus is original content and voice). Open-sourcing converts the "anyone can clone this" threat into credibility and is hard to attack later (can't un-open-source). 2. Numbers at our realistic scale (organic-only distribution, maybe 1-2k users year 1): donations typically convert 0.1-1% of users at ~5-10 CHF one-off, i.e. a few hundred CHF/yr; the 39 CHF license at ~2% conversion would be ~1,300 CHF/yr. So at small scale BOTH are pocket change; the license only massively out-earns donations if the product reaches 20-50k users (license ~13-33k CHF/yr vs donations ~1-5k). Given "no significant marketing" is a stated premise, that scale is unlikely, so the foregone license upside is modest. 3. Cost side: hosting ~110 CHF/yr; donations cover that trivially. Donations also DELETE infrastructure: no Paddle approval, no BTCPay entitlement flow, no license keys, no grandfathering problem, no VAT questions (pure donations are not taxable supplies). Phase 3 shrinks to almost nothing. 4. Practicalities: PWA needs a Capacitor APK for F-Droid (their builders or a compliant self-run repo, reproducible-build friendliness, some lag); quicker interim path is GitHub releases + Obtainium, F-Droid later. Publish server code too; expect tech users to self-host and never donate, accept that. GitHub/Liberapay/Ko-fi handles must live under the brand identity, never the personal one (pen-name discipline extends to the repo org). 5. Trade-offs to accept: donation revenue is unreliable and reputation-volatile; some users who WOULD pay 39 CHF donate 5; hosting donations must actually cover growth (bandwidth) or the hosted service becomes a liability; and a later switch to paid Pro after years of "donate if you value it" is a trust risk (same retroactive-paywall concern as before, amplified). 6. Recommendation: coherent option, support it IF the goal is impact + cost coverage rather than side income. Keep one hedge: the `plan` field idea from the roadmap (paid tier switchable later without schema change) stays in, and any future paid tier must be NEW additive features introduced before wide launch, never what donors already got. Kill criterion for the model: if hosted costs exceed ~3x donation income for two consecutive quarters and user count is growing, re-open monetization before costs bite. 7. Decision status: ADOPTED by user 2026-10-05 (see Decided). ### 2026-10-05 — Follow-up: does the donation model force identity disclosure? And the OSS-workout-app gap Identity: mostly no in the visible layer, partially yes in the rails. - Content/marketing layer unchanged: articles and app copy stay pen-named ("the Profectus team"). Open source changes nothing there; a public repo under a brand handle is normal and does not require a real name. - Legal rails still carry a real identity somewhere, but not publicly promoted: (a) the hosted service still processes EU/CH users' personal data, so GDPR/revDSG require an identifiable, contactable controller in the privacy policy even for a free service; (b) donation platforms verify identity to the platform (GitHub Sponsors/Ko-fi verification, Liberapay payout account) without publishing it; (c) a bank/IBAN visible to donors would leak the name, so route donations through platform balances or a dedicated account. Practical shape: minimal imprint = brand + real name + c/o address on ONE legal page; pseudonymity everywhere else. Pure donation solicitation (no goods sold) sits lighter under UWG than sales, but keep the minimal imprint as safe practice. Fully anonymous vendor remains impossible — as already established for sales, this does not change for donations. OSS-market check (verified via F-Droid listings / GitHub 2026-10-05): the "solid workout apps in OSS are scarce" premise is only half true. F-Droid already has LibreFit (800+ exercises, Material 3, active), Spix (React Native, rep counter), Gym Bott, Train Libre (Flutter, wger-based DB), GetFitPro (Kotlin/Compose, 1,300+ exercises), plus wger itself. What is genuinely scarce in that set: (1) a METHOD app — none carries a specific training system (rest-pause, partial-set progression logic, warm-up circuit, pain gating, curated programs); they are all generic loggers; (2) multi-device SYNC — nearly all are local-only, some explicitly anti-cloud; Profectus's sync + anonymous accounts is a real differentiator for exactly that audience (GrapheneOS/Calyx users want privacy AND device portability, and currently must choose one); (3) a content/community layer attached to the app (the article corpus). So positioning should be "the rest-pause method app, open source, with sync", not "an open source workout tracker", otherwise it competes head-on with five adequate free trackers and loses on features-per-effort. Practical additions if adopted: F-Droid metadata needs a Capacitor APK (or ship PWA + APK both); the OSS pitch belongs in the Extra tab and landing page ("no account required, self-host the server, audit the code"); donations UI follows OSS conventions (Ko-fi/Liberapay + GitHub Sponsors links, one line, no nag). ### 2026-10-05 — Architecture: local-first default + user-owned file backups + optional paid hosted sync (rxresu.me / open-core model); F-Droid policy check User's proposal: app works fully offline/local by default; automatic backups of logs+setup to a user-chosen device folder that the user syncs to Nextcloud/Syncthing (user's responsibility); optional registered-account sync hosted by us, potentially monetized. Explicit question: does monetizing opt-in cloud sync break F-Droid policy? Architecture assessment: 1. Local default: ALREADY TRUE. Dexie-first, "Continue without an account" path, server only used after login. Nothing to build; the pitch just needs to say it. 2. Folder backups: the JSON backup export exists but is manual. True "automatic backup to a phone folder the user's Nextcloud/Syncthing client syncs" is realistically an APK-only capability: Chrome/PWA on Android cannot persistently write an arbitrary user-chosen folder (no showDirectoryPicker on Android; OPFS is app-private and invisible to Nextcloud apps). In the Capacitor wrapper: SAF directory picker once, then write a timestamped JSON snapshot after each workout completion / on app close. Cheap to build (~days), fits the trust story. PWA fallback: manual export + scheduled reminder. Note: automatic = per-workout snapshot files with retention (keep last N) so the synced folder doesn't grow forever. 3. Hosted sync: the server exists (zero-dep node:sqlite rows table, LWW pull/push). Selling MANAGED sync as a subscription is the Bitwarden/open-core model and does NOT contradict the architecture. It DOES touch the standing "Rejected: gating sync/cloud backup of user data (trust killer)" idea-bank item, so this needs an explicit user decision to overturn/reshape. The honest reframe that resolves the tension: we never sell access to user DATA or app features; we sell the convenience of running the server (storage, availability, backups) while local mode + folder backups + self-hosting remain fully free. Precedents: Mullvad (self-hostable software, paid service), Bitwarden, rxresu.me's self-host-vs-hosted split. Concrete guardrails: server URL configurable in-app (default ours, any instance accepted); export-everything always free; zero app features gated on payment; cancellation = account keeps working until period end, data exportable, no lock-in mechanics. 4. F-Droid policy verdict (verified against fdroid.org docs + forum, 2026-10-05): NO breakage, and no anti-feature label needed. NonFreeNet applies only when the app "promotes or depends entirely on a non-free network service" AND there is no simple configuration option pointing to an alternative, publicly available, self-hostable free-software server instance. Our server is FOSS + self-hostable + URL-configurable, so even a paid hosted tier does not trigger NonFreeNet (contrast: ProtonVPN/Mullvad apps get flagged because no self-host swap; GitLab clients don't because GitLab is self-hostable). TetheredNet likewise avoided by the configurable URL. One hard rule: NO Google Play Billing / in-app payment in the F-Droid build; purchase happens on the website (Paddle/BTCPay), the app accepts an entitlement key or the account just flips server-side. Paid features in listed F-Droid apps are accepted practice (OsmAnd, My Expenses), ideally disclosed in the changelog/description. 5. Pricing shape if adopted: subscription (~15-25 CHF/yr) via MoR; per-user marginal cost near zero (workout rows are bytes; CX22 serves thousands of sync users). This is the strongest monetization candidate discovered so far BECAUSE it sells a running service, not features, and coexists cleanly with the donation/OSS positioning (donations = goodwill, sync subscription = the one thing worth paying for). 6. Decision status: ADOPTED by user 2026-10-05 (see Decided). ### 2026-10-05 — Can GitHub Pages replace the hosted website for free? Verified against GitHub's ToS (docs.github.com, GitHub Pages limits, 2026-10-05): "GitHub Pages is not intended for or allowed to be used as a free web hosting service to run your online business, e-commerce site, or any other website that is primarily directed at either facilitating commercial transactions or providing commercial software as a service (SaaS). Some monetization efforts are permitted on Pages, such as donation buttons and crowdfunding links." Also "Pages sites shouldn't be used for sensitive transactions like sending passwords." Verdict: NO for the app + landing once paid sync exists. - Landing + docs + donations-only: allowed (donation buttons explicitly permitted). Fine while monetization is donations. - Serving the APP from Pages once a paid sync tier exists = facilitating commercial transactions / providing SaaS → ToS violation territory; hosting a login screen on Pages also collides with the "no passwords over Pages" guidance. A ToS takedown of the app's home is a worse failure mode than 4.50 CHF/mo. - The VPS is needed REGARDLESS for the hosted sync server, so serving the PWA + landing from it (Caddy, already in Phase 1) is ~zero marginal cost. GitHub Pages remains useful for free: the public repo, README/docs, issue tracker, and optionally a static mirror for the F-Droid metadata. CI bonus: GitHub Actions can build the APK on every tag. - Privacy posture also favors the VPS: claiming "no third parties" is cleaner when the app itself is not served from GitHub/Microsoft infrastructure. - Clarification (user follow-up): yes — the line is "sell/serve from GitHub" vs "mention and link from GitHub". The public repo README, docs site (Pages), and in-app info may freely DESCRIBE the hosted sync subscription and link to profectus.fit, where checkout happens. That is standard FOSS practice and not a ToS violation. What must NOT live on GitHub Pages: the runnable app/PWA itself and the login/checkout flow. Donations stay on GitHub Sponsors or out-links (Ko-fi/Liberapay); Sponsors identity verification is platform-internal, not public. ## Open questions - ~~Final pricing numbers and tier composition~~ RESOLVED 2026-10-05: no feature tier; donations public face + optional sync subscription ~15-25 CHF/yr (final number TBD at wiring time) - ~~Whether Pro is one-time, yearly, or both~~ RESOLVED: Pro feature license retired; sync subscription is yearly - ~~Timing: introduce Pro before or after public launch~~ RESOLVED: no Pro tier to introduce; sync subscription goes live with the hosted launch - Health-platform integration scope (Apple Health, Health Connect) - ~~License choice for the open-source release~~ DECIDED 2026-10-05: AGPL-3.0 for the whole repo (client + server). No CLA needed while only the owner contributes; revisit dual-licensing only if a partner ever demands permissive terms. Stores unaffected (Play/F-Droid fine; iOS later as owner-distributor). - F-Droid shipping route: official F-Droid builders vs self-run compliant repo; interim GitHub releases + Obtainium ### 2026-10-05 — Big-screen analytics as a sync driver (phone logs, desktop analyzes) User's idea: keep phone-side analytics light (screen size), build deeper analytics for the web/desktop experience later; since users log on the phone, deep web analytics effectively requires sync, gently driving the sync subscription. Assessment: 1. Technical reality first: there is no separate "web app" — the PWA and the future Capacitor APK are the same codebase. "Desktop analytics" therefore means responsive/large-screen layout layers (wider charts, multi-panel views, comparisons), not a second product. The AnalyticsProgress/Stats views render from the same Dexie data either way. 2. Compliance with the decided rule: deep analytics must ship FREE on the desktop web, and must work with ANY sync target — our hosted server AND a self-hosted instance. Then it is not a paywall disguised as a feature gap; the only thing money buys remains running our server. What would violate the rule: making the desktop analytics reachable only through OUR paid endpoint. 3. Honest nudge assessment: for non-technical users the free paths to desktop analytics are (a) paid-ish hosted sync at ~15-25 CHF/yr, (b) self-hosting (too technical for most), (c) CSV export to a spreadsheet (free but clumsy). So yes, it functions as a conversion driver toward the subscription, and that is acceptable precisely because the guardrails hold: nothing is gated, the feature is free, and a technically-capable user can reach it for 0 CHF. The nudge is convenience-shaped, not hostage-shaped. Keep the CSV export good enough that the free path is real (export already exists; it is the designated escape hatch, keep it maintained). 4. Analytics itself stays free per the no-feature-paywalls decision (the old idea-bank "analytics = Pro" proposal is retired). Donations remain the goodwill channel; sync subscription the convenience channel. 5. Sequencing note: do NOT build deep analytics before the sync path is solid — big-screen analytics without sync is a dead end for phone-first users and burns effort on the wrong side. Order: sync (incl. self-host URL config) → then desktop analytics layers. Also keep phone-side analytics present but light (streaks, e1RM, volume trend) so phone-only users are not second-class, just smaller-screened. 6. F-Droid angle: desktop analytics runs in the PWA, not the APK, so nothing extra ships into the F-Droid build; no policy impact. Decision status: direction agreed in discussion; implementation gated on sync build (Phase 3 of launch roadmap), no separate go needed beyond the roadmap go. ### 2026-10-05 — License options briefing (economic impact, in prep for the OSS release) Candidates and what they mean for Profectus specifically: - **MIT/X11:** simplest, most permissive; anyone can fork, embed, close, and commercialize without contributing back. Economic impact: zero protection for the hosted-sync revenue. A well-funded competitor could take the client+server code, add their own hosting, and outcompete profectus.fit with our own work. Fine only if we truly don't care about the subscription upside. - **Apache-2.0:** permissive like MIT plus an explicit patent grant and patent-retaliation clause (if a sue-happy patent holder sues users of the fork, they lose the license). Slightly more corporate-friendly; same economic exposure as MIT re: closed SaaS forks. Effectively MIT with legal polish. - **AGPL-3.0:** strong copyleft; the "network clause" (§13) makes anyone who modifies the code and offers it AS A SERVICE owe their users the modified source. Effect: a competitor cannot build a closed hosted sync service on our code without releasing their modifications. This is the one license that directly protects the paid-sync business model. Cost: some companies ban AGPL deps in products (Google famously) — irrelevant for a consumer fitness app and actually on-brand for the F-Droid/GrapheneOS audience; F-Droid has no problem with AGPL. Trade-off: technically incompatible-linkage with permissive libraries is a non-issue here (we own all the code); dual-licensing later is possible but requires consent of all contributors (keep a CLA or only self-contribute). - **(MPL-2.0, mentioned for completeness):** file-level copyleft middle ground; protects modifications to our files but allows closed larger works. Weaker than AGPL for the SaaS case; no network clause. Recommendation: AGPL-3.0 for the whole repo (client + server — the server is where the SaaS risk lives). Trademark/name protection is separate from the license and still applies. If a partner/integration ever demands permissive terms, decide dual-licensing then. Clarification (stores): AGPL does NOT prevent Play Store or App Store distribution. Google Play has no license restriction — GPL-family apps ship there routinely. Apple's case is subtler: Apple's standard developer T&Cs historically conflicted with GPL redistribution, but as the COPYRIGHT HOLDER the user may distribute his own AGPL work under Apple's terms too (the owner can accept additional terms for his own code; third parties could not). FSF holds the same position. Practical rule: if/when an iOS build (Capacitor wrapper) ever ships, the user distributes it himself from the owning account, and the repository keeps the AGPL notice. ### 2026-10-05 — iOS reach and donations (market-size realization) Path for iPhone users, in order of preference: 1. **PWA first, no App Store needed.** The app already runs in iOS Safari; home-screen install (A2HS) works since iOS 16.4, with push notification support and its own storage. Distribution = the landing page. Donations via web links (Ko-fi/Sponsors) are unrestricted — no Apple commission, no IAP rules. This is the zero-work iOS channel. 2. **App Store later, only if needed.** AGPL does not block it (copyright holder may ship his own work under Apple's terms; see license briefing above). Costs: $99/yr Apple dev account, review process, and DONATION caution: Apple requires IAP for digital goods tied to an app; pure donations to a charity can go outside IAP, but personal-developer donation links inside an iOS app are a gray zone Apple has rejected apps over. If the app ships on iOS, the donate link should be conservative (donations via the website, not in-app). EU adds external-link/alternative-store entitlements since 2024-25 (DMA), but that machinery is not worth building at our scale. 3. **iOS PWA storage eviction risk (important for sync demand):** Safari can purge IndexedDB data of web apps that go unused (ITP 7-day rule for script-writable storage; home-screen PWAs get more persistent storage but still less robust than native). Consequence: an iPhone-only user who trains sporadically risks losing local data. Mitigations to build: recommend A2HS install, nudge folder/manual backups, and note that hosted sync (paid tier) genuinely solves this. So the iOS market does not just add donations — it materially strengthens the paid-sync case, because Apple's storage behavior makes sync a safety feature there. Conclusion: AGPL stays; iOS is reachable PWA-first at ~zero cost, App Store as an optional later step with the donation-link caveat, and the paid sync story is strongest exactly where Apple's storage policy is weakest.