max / makenotwork
189 files changed,
+0 insertions,
-14048 deletions
| @@ -1,71 +0,0 @@ | |||
| 1 | - | # DONE: Add App + SyncKit Revenue to Financial Projections | |
| 2 | - | ||
| 3 | - | **Completed 2026-05-03.** App sync revenue added to `financial_dashboard.md` (adoption scenarios, combined break-even, impact on sustainable/comfortable thresholds) and `economics.md` (app sync revenue section, See Also links). SyncKit SDK noted as future stream, not yet in projections. | |
| 4 | - | ||
| 5 | - | ## What's missing | |
| 6 | - | ||
| 7 | - | The financial dashboard (`financial_dashboard.md`) and economics model (`economics.md`) only project revenue from **creator subscriptions** and **Fan+**. They do not include revenue from the three desktop apps or a productized SyncKit SDK. | |
| 8 | - | ||
| 9 | - | These streams have near-zero marginal cost since the SyncKit infrastructure already exists and runs on the same Hetzner VPS. Including them will lower the break-even creator count and improve runway projections. | |
| 10 | - | ||
| 11 | - | ## Revenue streams to add | |
| 12 | - | ||
| 13 | - | ### 1. GoingsOn sync | |
| 14 | - | - Source: `app_sync_pricing.md` | |
| 15 | - | - Price: $2/month or $15/year | |
| 16 | - | - Net after Stripe: ~$1.64/month or ~$14.26/year ($1.19/month effective) | |
| 17 | - | - Infra cost per user: negligible (metadata only, 1-5 MB) | |
| 18 | - | - Margin: ~80%+ | |
| 19 | - | ||
| 20 | - | ### 2. Balanced Breakfast sync | |
| 21 | - | - Source: `app_sync_pricing.md` | |
| 22 | - | - Price: $1/month or $8/year | |
| 23 | - | - Net after Stripe: ~$0.67/month or ~$7.47/year ($0.62/month effective) | |
| 24 | - | - Infra cost per user: negligible (~1 MB per user) | |
| 25 | - | - Margin: ~90%+ | |
| 26 | - | ||
| 27 | - | ### 3. audiofiles sync (blob tiers) | |
| 28 | - | - Source: `app_sync_pricing.md` | |
| 29 | - | - Price: $1-8/month or $10-80/year (tiered by storage) | |
| 30 | - | - Margins: 58-83% depending on tier | |
| 31 | - | - This is the only app with meaningful per-user infra cost (S3 storage for sample files) | |
| 32 | - | ||
| 33 | - | ### 4. SyncKit SDK (B2B, future) | |
| 34 | - | - Source: `synckit_pricing.md` | |
| 35 | - | - Not yet productized, but planned | |
| 36 | - | - Revenue from indie developers using SyncKit as sync-as-a-service | |
| 37 | - | - Pricing TBD but model exists in synckit_pricing.md | |
| 38 | - | ||
| 39 | - | ## What to update | |
| 40 | - | ||
| 41 | - | ### `financial_dashboard.md` | |
| 42 | - | - Add app sync revenue section alongside creator subscriptions and Fan+ | |
| 43 | - | - Model conservative, moderate, and optimistic adoption scenarios | |
| 44 | - | - Recalculate break-even and self-sustaining thresholds with combined revenue | |
| 45 | - | ||
| 46 | - | ### `economics.md` | |
| 47 | - | - Add section for app revenue streams | |
| 48 | - | - Note that these are independent of creator platform growth (different user base) | |
| 49 | - | ||
| 50 | - | ## Suggested scenarios to model | |
| 51 | - | ||
| 52 | - | | Scenario | GO users | BB users | AF users (avg $3/mo) | Monthly app revenue | | |
| 53 | - | |----------|----------|----------|----------------------|---------------------| | |
| 54 | - | | Conservative (6 mo) | 50 | 30 | 20 | $162 (50·$1.64 + 30·$0.67 + 20·$3.00 = $82 + $20.10 + $60 = $162) | | |
| 55 | - | | Moderate (12 mo) | 200 | 100 | 50 | $545 (200·$1.64 + 100·$0.67 + 50·$3.00 = $328 + $67 + $150 = $545) | | |
| 56 | - | | Optimistic (18 mo) | 500 | 300 | 150 | $1,471 (500·$1.64 + 300·$0.67 + 150·$3.00 = $820 + $201 + $450 = $1,471) | | |
| 57 | - | ||
| 58 | - | ### Impact on break-even | |
| 59 | - | ||
| 60 | - | Current break-even: ~32-36 creators (covers $580/month fixed costs per expenses.md from creator subs alone). | |
| 61 | - | ||
| 62 | - | If app sync revenue covers infrastructure costs: | |
| 63 | - | - At moderate adoption (~$545/month per moderate scenario): app-sync revenue is comparable to ops-only fixed cost ($580/mo). Creator subscriptions then approach pure margin. | |
| 64 | - | - Break-even creator count drops to effectively **0 for infrastructure** — first creator subscription dollar is profit. | |
| 65 | - | - Self-sustaining threshold (covers $3K salary + infra) drops from ~295 creators to ~200-220 creators. | |
| 66 | - | ||
| 67 | - | ## Notes | |
| 68 | - | - Apps are distributed independently of the creator platform. App users ≠ creator platform users. These are separate acquisition funnels. | |
| 69 | - | - GoingsOn is the most likely to drive sync revenue early (productivity apps have higher willingness to pay for sync than feed readers). | |
| 70 | - | - audiofiles has the highest per-user revenue potential but the smallest addressable market. | |
| 71 | - | - Annual billing should be pushed over monthly — better margins due to Stripe fee structure. |
| @@ -1,90 +0,0 @@ | |||
| 1 | - | # App Sync Pricing | |
| 2 | - | ||
| 3 | - | How SyncKit cloud sync is priced for MNW desktop apps (GO, BB, AF). This is consumer-facing pricing, separate from the B2B developer pricing in [synckit_pricing.md](../../synckit_pricing.md). | |
| 4 | - | ||
| 5 | - | ## Guiding Principles | |
| 6 | - | ||
| 7 | - | - Annual billing preferred. Small monthly charges lose a disproportionate amount to Stripe's $0.30 per-transaction fee. Annual pricing passes that savings to the user. | |
| 8 | - | - Priced relative to actual costs where costs are meaningful (AF blob tiers). Priced for development sustainability where costs are negligible (BB, GO metadata sync). | |
| 9 | - | - No overages, ever. When storage is full, sync degrades gracefully. | |
| 10 | - | - Metadata sync is free for AF (the only app with a separate blob tier). BB and GO sync metadata only, so their subscription covers everything. | |
| 11 | - | ||
| 12 | - | ## Balanced Breakfast | |
| 13 | - | ||
| 14 | - | **App price:** Free. | |
| 15 | - | **Sync is the only monetization.** | |
| 16 | - | ||
| 17 | - | BB syncs ~1 MB per user (feed configs, bookmarks, read state, tags, user config). No blobs. Infrastructure cost per user is negligible. | |
| 18 | - | ||
| 19 | - | | Plan | Price | Stripe fees | Net to MNW | Effective monthly | | |
| 20 | - | |------|-------|-------------|------------|-------------------| | |
| 21 | - | | Monthly | $1/mo | ~$0.33/mo | ~$0.67/mo | $0.67 | | |
| 22 | - | | Annual | $8/yr | ~$0.53/yr | ~$7.47/yr | $0.62 | | |
| 23 | - | ||
| 24 | - | Annual pricing exists because payment processing fees on small monthly charges are disproportionate. This is stated openly. | |
| 25 | - | ||
| 26 | - | **What's included:** Full cloud sync across all devices — feeds, bookmarks, read state, tags, settings. Everything BB stores. | |
| 27 | - | ||
| 28 | - | ## GoingsOn | |
| 29 | - | ||
| 30 | - | **App price:** Free. | |
| 31 | - | **Sync is the only monetization.** | |
| 32 | - | ||
| 33 | - | GO syncs tasks, subtasks, contacts, email accounts, events, milestones, attachments, annotations, and related tables. Metadata is small (1-5 MB). Some users sync email attachments as blobs, but most don't. Attachment sync is included — the few heavy users are subsidized by the majority. | |
| 34 | - | ||
| 35 | - | | Plan | Price | Stripe fees | Net to MNW | Effective monthly | | |
| 36 | - | |------|-------|-------------|------------|-------------------| | |
| 37 | - | | Monthly | $2/mo | ~$0.36/mo | ~$1.64/mo | $1.64 | | |
| 38 | - | | Annual | $15/yr | ~$0.74/yr | ~$14.26/yr | $1.19 | | |
| 39 | - | ||
| 40 | - | Higher than BB because GO has a larger sync surface (more tables, blob support, more development investment). | |
| 41 | - | ||
| 42 | - | **What's included:** Full cloud sync across all devices — tasks, contacts, events, email accounts, attachments, everything GO stores. | |
| 43 | - | ||
| 44 | - | ## audiofiles | |
| 45 | - | ||
| 46 | - | **App price:** PWYW, suggested $15, floor $0. | |
| 47 | - | **Sync is the recurring revenue floor.** | |
| 48 | - | ||
| 49 | - | AF is the only app where sync costs scale meaningfully. Sample libraries can be gigabytes. The app purchase (when paid) covers development value. Sync pricing covers infrastructure. | |
| 50 | - | ||
| 51 | - | **Metadata sync is free.** Sample metadata, analysis data, VFS structure, collections, tags, edit history — all synced at no cost. This makes AF useful across devices even without paying for sync. | |
| 52 | - | ||
| 53 | - | **Blob sync (sample files) is tiered by storage:** | |
| 54 | - | ||
| 55 | - | | Tier | Storage | Monthly | Annual | Infra cost | Margin | | |
| 56 | - | |------|---------|---------|--------|------------|--------| | |
| 57 | - | | Light | 10 GB | $1/mo | $10/yr | ~$0.17/mo | ~83% | | |
| 58 | - | | Standard | 50 GB | $3/mo | $30/yr | ~$0.85/mo | ~72% | | |
| 59 | - | | Large | 200 GB | $8/mo | $80/yr | ~$3.40/mo | ~58% | | |
| 60 | - | ||
| 61 | - | Margins are intentionally modest — AF sync is near-cost, not a profit center. The PWYW app purchase is the primary revenue event. | |
| 62 | - | ||
| 63 | - | Blob sync activates per-VFS via the `sync_files` flag. Users control exactly which folders sync samples and which sync metadata only. | |
| 64 | - | ||
| 65 | - | **What's included in each tier:** Storage allocation for synced sample files. When storage is full, new blob uploads are rejected but metadata sync continues. Upgrade tier to increase capacity. | |
| 66 | - | ||
| 67 | - | ## Stripe Fee Context | |
| 68 | - | ||
| 69 | - | Why annual pricing is preferred, stated publicly: | |
| 70 | - | ||
| 71 | - | > We prefer annual billing because payment processing fees on small monthly charges are disproportionate. On a $1/month charge, Stripe takes ~33%. On a $12/year charge, Stripe takes ~5%. Annual pricing passes that savings to you. | |
| 72 | - | ||
| 73 | - | ## Relationship to MNW Creator Tiers | |
| 74 | - | ||
| 75 | - | None. SyncKit is a separate product marketed at developers. App sync pricing is independent of MNW creator subscriptions. A creator paying $30/mo for Big Files still pays separately for GO/BB/AF sync like any other user. | |
| 76 | - | ||
| 77 | - | MNW may eventually offer creators a cloud storage budget as part of their tier (for project files, assets, etc.), but that would be a separate MNW feature, not SyncKit. | |
| 78 | - | ||
| 79 | - | ## Implementation | |
| 80 | - | ||
| 81 | - | - [x] Stripe pricing for BB sync — inline price_data ($1/mo, $8/yr), migration 098 | |
| 82 | - | - [x] Stripe pricing for GO sync — inline price_data ($2/mo, $15/yr) | |
| 83 | - | - [x] Stripe pricing for AF blob tiers — inline price_data (3 tiers, monthly + annual) | |
| 84 | - | - [x] Sync gate in BB: server 402 on push/pull, scheduler 1h backoff, settings subscribe UI | |
| 85 | - | - [x] Sync gate in GO: server 402 on push/pull, scheduler 1h backoff, settings subscribe UI | |
| 86 | - | - [x] Sync gate in AF: metadata ungated, server 402 on blob endpoints, egui tier selector + storage bar | |
| 87 | - | - [x] Webhook handling: checkout.session.completed creates record, subscription.updated/deleted/invoice events handled | |
| 88 | - | - [ ] Upgrade/downgrade flow for AF tiers | |
| 89 | - | - [ ] Cancellation: sync stops at end of billing period, data retained 30 days | |
| 90 | - | - [ ] Test end-to-end against live Stripe |
| @@ -1,171 +0,0 @@ | |||
| 1 | - | # Assumptions — Master Table | |
| 2 | - | ||
| 3 | - | **As of: 2026-05-16.** | |
| 4 | - | **Maintained alongside every doc that depends on these values.** | |
| 5 | - | ||
| 6 | - | Every numeric assumption used anywhere in MNW's business documentation. Each has: | |
| 7 | - | - A current value (or "unmeasured" if pre-launch) | |
| 8 | - | - A measurement proxy (SQL query, metric pointer, or observation method) | |
| 9 | - | - A review cadence | |
| 10 | - | - A last-verified date | |
| 11 | - | ||
| 12 | - | When a doc cites a number, it should reference `assumptions.md#A<ID>` rather than restate the value. When this file's value changes, downstream docs need not change. | |
| 13 | - | ||
| 14 | - | Conventions: | |
| 15 | - | - "Unmeasured" = pre-launch; no creators yet to measure. | |
| 16 | - | - "SQL" = a query against the production database (run monthly unless noted). | |
| 17 | - | - "Manual" = an observation logged by hand. | |
| 18 | - | - "Vendor" = pulled from a vendor's dashboard (Cloudflare, Postmark, Stripe, etc.). | |
| 19 | - | ||
| 20 | - | --- | |
| 21 | - | ||
| 22 | - | ## A1–A10 — Storage and payload assumptions | |
| 23 | - | ||
| 24 | - | | ID | Assumption | Current | Proxy | Cadence | Last verified | | |
| 25 | - | |---|---|---|---|---|---| | |
| 26 | - | | **A1** | Avg storage / Basic creator | ~100 MB | `SELECT AVG(storage_used_bytes) FROM creator_subscriptions JOIN storage_usage USING(creator_id) WHERE tier='basic' AND active` | monthly | unmeasured | | |
| 27 | - | | **A2** | Avg storage / Small Files creator | ~2 GB | same, `tier='small_files'` | monthly | unmeasured | | |
| 28 | - | | **A3** | Avg storage / Big Files creator | ~10 GB | same, `tier='big_files'` | monthly | unmeasured | | |
| 29 | - | | **A4** | Tier mix (% of active creators per tier) | 40/30/20/10 | see `tier_mix.md` | monthly | unmeasured | | |
| 30 | - | | **A5** | Avg variable cost / creator | ~$1 (View B) | (monthly Hetzner cost) / (active creator count) | monthly | unmeasured | | |
| 31 | - | | **A6** | Cloudflare cache-hit ratio | unmeasured | CF Analytics dashboard monthly | monthly | — | | |
| 32 | - | | **A7** | Hetzner egress vs 1TB included/server | unmeasured | Hetzner invoice GB egress per server | monthly | — | | |
| 33 | - | | **A8** | BB sync payload / user | ~1 MB | `SELECT AVG(SUM(payload_size)) FROM synckit_log WHERE app='balanced_breakfast' GROUP BY user_id` | monthly | unmeasured | | |
| 34 | - | | **A9** | GO sync payload / user | 1-5 MB | same, `app='goingson'` | monthly | unmeasured | | |
| 35 | - | | **A10** | AF blob bytes / user / tier | tier-dependent | same, `app='audiofiles'`, grouped by tier | monthly | unmeasured | | |
| 36 | - | ||
| 37 | - | --- | |
| 38 | - | ||
| 39 | - | ## A11–A20 — Pricing, fees, infrastructure | |
| 40 | - | ||
| 41 | - | | ID | Assumption | Current | Proxy | Cadence | Last verified | | |
| 42 | - | |---|---|---|---|---|---| | |
| 43 | - | | **A11** | SyncKit default burst multiplier | 5× | `SELECT app_id, SUM(bytes_transferred)/SUM(bytes_stored) FROM sync_metrics GROUP BY app_id` | monthly | unmeasured | | |
| 44 | - | | **A12** | Chargeback rate (creator tier subs) | 0.1-0.15% | `disputes / charges` from Stripe events | quarterly, recalibrate at N≥1000 | unmeasured | | |
| 45 | - | | **A13** | Median fan-to-creator item price | $15 | `SELECT PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY price_cents) FROM items` | quarterly | unmeasured | | |
| 46 | - | | **A14** | Creator-approval median latency | claim: 1 business day | `SELECT PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY (decided_at - submitted_at)) FROM creator_applications WHERE decided_at IS NOT NULL` | monthly | unmeasured | | |
| 47 | - | | **A15** | Stripe fee per tier (canonical) | per `stripe_fees.md` | `SELECT tier, AVG(stripe_fee_cents) FROM creator_subscription_invoices GROUP BY tier` | monthly | static reference (formula) | | |
| 48 | - | | **A16** | DB pool capacity → concurrent users | pool=25 → assumed ~200 users | `pg_stat_activity` p95 + load test | quarterly | pool=25 verified (`constants.rs:8`); 200 user inference unverified | | |
| 49 | - | | **A17** | Founder weekly hours, 5-bucket time log | unmeasured | Weekly tally in a single text file: (1) feature dev (2) infra/deploy/monitoring (3) business/legal/docs/strategy (4) direct creator interaction (5) other | weekly | unmeasured | | |
| 50 | - | | **A18** | Postmark email volume vs free tier | <100 lifetime currently | Postmark dashboard | monthly | unmeasured | | |
| 51 | - | | **A19** | Fan+ redemption rate | unknown | `SELECT SUM(redeemed_cents)/NULLIF(SUM(issued_cents),0) FROM fan_plus_credits` | monthly (when shipped) | unmeasured | | |
| 52 | - | | **A20** | Fixed-cost step at 500 / 2000 creators | +$100 / +$400 over baseline | Itemize trigger (e.g., CCX23 upgrade at N=X, add LB at N=Y, etc.) | one-time spec, then verify on threshold | spec only | | |
| 53 | - | ||
| 54 | - | --- | |
| 55 | - | ||
| 56 | - | ## A21–A25 — Chargeback fund and miscellaneous | |
| 57 | - | ||
| 58 | - | | ID | Assumption | Current | Proxy | Cadence | Last verified | | |
| 59 | - | |---|---|---|---|---|---| | |
| 60 | - | | **A21** | Reserve multiplier (chargeback fund) | 2.5× | Poisson 95th-percentile at participant count N | quarterly | needs derivation | | |
| 61 | - | | **A22** | Min participating creators (chargeback fund) | 50 | Variance ratio threshold | one-time | needs derivation | | |
| 62 | - | | **A23** | IBNR buffer (chargeback fund) | 120 days | Longest observed dispute lag | quarterly | sourced from Visa/MC chargeback windows | | |
| 63 | - | | **A24** | Compliance-cost / revenue threshold for licensing decision | undefined | (annual compliance cost) / (annual GMV) | annually | — | | |
| 64 | - | | **A25** | Build-size median (games, storage_cdn) | 300-600 MB | `PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY size_bytes) FROM items WHERE kind='game_build'` | one-time | unmeasured | | |
| 65 | - | ||
| 66 | - | --- | |
| 67 | - | ||
| 68 | - | ## A26–A30 — Post-audit framework assumptions | |
| 69 | - | ||
| 70 | - | These are the load-bearing assumptions for the pricing and reserve framework. Each is currently unmeasured; A26 and A27 in particular must reach 3+ months of data before the trajectory model in `pricing.md` can be acted on. | |
| 71 | - | ||
| 72 | - | ### A26 — Platform-overhead time per active creator | |
| 73 | - | ||
| 74 | - | **This is the load-bearing assumption for cost-to-deliver.** | |
| 75 | - | ||
| 76 | - | | Aspect | Detail | | |
| 77 | - | |---|---| | |
| 78 | - | | **Definition** | Time spent on platform-overhead work (development, infra/deploy/monitoring, business/legal/docs, plus *bucket-4 direct creator interaction* from A17), divided by active creator count. | | |
| 79 | - | | **Excludes** | T1 (bug-driven) and T2 (UX-error-driven) ticket time. Those are quality failures that go to dev / design queues, not pricing inputs. See A27. | | |
| 80 | - | | **Includes** | T3 (abuse-defense) time, which is genuinely per-N marginal and bounded by design. | | |
| 81 | - | | **Current value** | Unmeasured. No creators yet. | | |
| 82 | - | | **Proxy** | Monthly aggregate from A17 weekly time log (sum buckets 1-3 = platform overhead; bucket 4 = direct creator) ÷ active creator count from `creator_subscriptions`. | | |
| 83 | - | | **Cadence** | Monthly. Trajectory model in `pricing.md` needs ≥3 months of data before being acted on. | | |
| 84 | - | | **Notes** | The trajectory model rests entirely on this number. Misestimate by 2× and pricing decisions are wrong by ~$5/creator/mo at small N. | | |
| 85 | - | ||
| 86 | - | ### A27 — T1 / T2 / T3 ticket categorization at intake | |
| 87 | - | ||
| 88 | - | | Aspect | Detail | | |
| 89 | - | |---|---| | |
| 90 | - | | **Definition** | Every support contact tagged within 24 hours: T1 = bug report, T2 = UX-error / human-mistake report, T3 = abuse / bad-actor / time-waster. | | |
| 91 | - | | **Use** | Quality and abuse-defense signals. Not used as pricing input. | | |
| 92 | - | | **Disposition** | T1 → bug-fix queue. T2 → UX roadmap. T3 → abuse-defense queue. | | |
| 93 | - | | **Current value** | Unmeasured. No tickets yet. | | |
| 94 | - | | **Proxy** | Tag at intake; monthly count by tag from ticket store. | | |
| 95 | - | | **Cadence** | Monthly. T1 + T2 patterns reviewed quarterly to feed roadmap. | | |
| 96 | - | | **Notes** | If T1 + T2 rates rise faster than active creator count, that's a product-quality regression, not a sign to raise prices. | | |
| 97 | - | ||
| 98 | - | ### A28 — $R_\text{cap}$ formula and current value | |
| 99 | - | ||
| 100 | - | | Aspect | Detail | | |
| 101 | - | |---|---| | |
| 102 | - | | **Formula** | $R_\text{cap} = T_\text{fixed} \cdot F + S_\text{legal} + S_\text{shock}$ (see `reserve_policy.md`) | | |
| 103 | - | | **Current parameters** | $T_\text{fixed}$=12, $F$=$580, $S_\text{legal}$=$50K, $S_\text{shock}$=$5K | | |
| 104 | - | | **Current value** | $61,960 | | |
| 105 | - | | **Proxy** | Recompute when $F$ (`expenses.md` total) shifts >10% | | |
| 106 | - | | **Cadence** | Event-driven; full annual review in January | | |
| 107 | - | | **Last verified** | 2026-05-16 | | |
| 108 | - | ||
| 109 | - | ### A29 — Founding-cohort vs standard-rate signup velocity | |
| 110 | - | ||
| 111 | - | | Aspect | Detail | | |
| 112 | - | |---|---| | |
| 113 | - | | **Definition** | Monthly new-creator signups by rate class. The ratio is the first-order elasticity signal post-cohort-close. | | |
| 114 | - | | **Current value** | Unmeasured. No signups yet. | | |
| 115 | - | | **Proxy** | `SELECT rate_class, COUNT(*) FROM creator_subscriptions WHERE created_at >= date_trunc('month', NOW()) - INTERVAL '1 month' AND created_at < date_trunc('month', NOW()) GROUP BY rate_class` | | |
| 116 | - | | **Cadence** | Monthly after cohort closes. Quarterly comparison report. | | |
| 117 | - | | **Last verified** | unmeasured | | |
| 118 | - | | **Notes** | The most informative signal for whether future price cuts (or rises) make sense. | | |
| 119 | - | ||
| 120 | - | ### A30 — Reserve balance vs $R_\text{cap}$ | |
| 121 | - | ||
| 122 | - | | Aspect | Detail | | |
| 123 | - | |---|---| | |
| 124 | - | | **Definition** | Current company safety-reserve balance divided by $R_\text{cap}$ from A28. | | |
| 125 | - | | **Current value** | $0 / $61,960 = 0% | | |
| 126 | - | | **Proxy** | Bank balance reading on first business day of month | | |
| 127 | - | | **Cadence** | Monthly, logged in `reserve_policy.md` header or separate ledger | | |
| 128 | - | | **Last verified** | 2026-05-16 (zero baseline) | | |
| 129 | - | | **Notes** | When this first reaches 100%, the surplus disposition rule in `reserve_policy.md` §4 activates and surplus begins flowing to $R_\text{opp}$ (A31). | | |
| 130 | - | ||
| 131 | - | ### A31 — Opportunistic fund ($R_\text{opp}$) | |
| 132 | - | ||
| 133 | - | | Aspect | Detail | | |
| 134 | - | |---|---| | |
| 135 | - | | **Definition** | Bounded discretionary fund for event sponsorship, opportunistic marketing, charitable contributions, strategic gifts. Separate from $R_\text{cap}$. | | |
| 136 | - | | **Cap** | $10,000 | | |
| 137 | - | | **Spend rules** | Per-incident max $2,500 (25% of cap); annual aggregate max $5,000 (50% of cap, rolling 12 months) | | |
| 138 | - | | **Current balance** | $0 | | |
| 139 | - | | **Proxy** | Bank balance for $R_\text{opp}$ sub-account or earmark; ledger entries for spend | | |
| 140 | - | | **Cadence** | Monthly balance check; monthly rolling-spend check; annual disclosure | | |
| 141 | - | | **Last verified** | 2026-05-16 (zero baseline) | | |
| 142 | - | | **Notes** | Replenishes from surplus only after $R_\text{cap}$ is at 100%. Excluded categories: founder comp, ongoing ops, hiring. See `reserve_policy.md` §3 for full spec. | | |
| 143 | - | ||
| 144 | - | --- | |
| 145 | - | ||
| 146 | - | ## Quick-reference: which docs cite which assumptions | |
| 147 | - | ||
| 148 | - | | Doc | Cites | | |
| 149 | - | |---|---| | |
| 150 | - | | `pricing.md` | A4, A15, A26, A27, A28, A29 | | |
| 151 | - | | `reserve_policy.md` | A20, A28, A30, A31 | | |
| 152 | - | | `partnerships.md` | A31 (annual disclosure of $R_\text{opp}$ spend) | | |
| 153 | - | | `tech_costs.md` | A1, A2, A3, A4, A5, A6, A7, A15 | | |
| 154 | - | | `economics.md` (internal) | A4, A5, A28 | | |
| 155 | - | | `chargeback_protection_fund.md` | A12, A13, A21, A22, A23 | | |
| 156 | - | | `synckit_pricing.md` | A11 | | |
| 157 | - | | `app_sync_pricing.md` | A8, A9, A10 | | |
| 158 | - | | `financial_dashboard.md` | A4, A15 | | |
| 159 | - | | `storage_cdn.md` | A6, A7, A25 | | |
| 160 | - | | `mtl_landscape.md` | A24 | | |
| 161 | - | | `business_sustainability_audit.md` | A16, A17 | | |
| 162 | - | ||
| 163 | - | --- | |
| 164 | - | ||
| 165 | - | ## Update protocol | |
| 166 | - | ||
| 167 | - | 1. When a value changes, edit this file (update value + "last verified" date). | |
| 168 | - | 2. Do not update individual doc references — they point at IDs here, so they're already current. | |
| 169 | - | 3. If a new assumption is needed in a doc, add a new row here first (next ID number), then cite from the doc. | |
| 170 | - | 4. If an assumption is retired (no longer used anywhere), mark the row strikethrough but keep it for historical context. Don't reuse IDs. | |
| 171 | - | 5. Each January, full review: which proxies have produced data, which haven't, which assumptions need recalibration. |
| @@ -1,222 +0,0 @@ | |||
| 1 | - | # MNW Business Assumptions — Machine-Readable Source of Truth | |
| 2 | - | # | |
| 3 | - | # Status: draft / not yet consumed by tooling. Target consumer is a future | |
| 4 | - | # docengine feature that substitutes `{{ key }}` placeholders in markdown | |
| 5 | - | # at build time. See `MNW/server/docs/todo.md` § "Docengine — assumption | |
| 6 | - | # substitution" for the proposed implementation. | |
| 7 | - | # | |
| 8 | - | # Until that feature ships, this file is informational. The canonical | |
| 9 | - | # values still live in the markdown docs listed in each section header. | |
| 10 | - | # | |
| 11 | - | # Conventions: | |
| 12 | - | # - All currency in USD unless suffixed `_eur`. | |
| 13 | - | # - All time in months unless suffixed `_days` / `_years`. | |
| 14 | - | # - Percentages as decimals (0.029 not 2.9). | |
| 15 | - | # - Each section names the canonical markdown source. | |
| 16 | - | # - Open decisions tagged `# OPEN:` — these are placeholder values | |
| 17 | - | # pending founder approval per `pricing.md` §7 and `reserve_policy.md` §8. | |
| 18 | - | # | |
| 19 | - | # As of: 2026-05-16 | |
| 20 | - | # Last manual-verified: 2026-05-16 | |
| 21 | - | ||
| 22 | - | ||
| 23 | - | # ─── Expenses (canonical: expenses.md) ──────────────────────────────────── | |
| 24 | - | [expenses] | |
| 25 | - | F_monthly = 580 # Total fixed monthly burn (rounded from $579.08) | |
| 26 | - | F_monthly_exact = 579.08 | |
| 27 | - | as_of = "2026-05-16" | |
| 28 | - | ||
| 29 | - | [expenses.lines] | |
| 30 | - | hetzner = 31.00 | |
| 31 | - | coworking_industrious = 332.00 | |
| 32 | - | claude_code = 200.00 | |
| 33 | - | fastmail = 5.00 | |
| 34 | - | domains = 2.00 | |
| 35 | - | cloudflare = 0.00 | |
| 36 | - | postmark = 0.00 | |
| 37 | - | apple_developer_amortized = 8.25 # $99/yr ÷ 12 | |
| 38 | - | co_llc_periodic_amortized = 0.83 # $10/yr ÷ 12 | |
| 39 | - | ||
| 40 | - | ||
| 41 | - | # ─── Stripe fees (canonical: stripe_fees.md) ────────────────────────────── | |
| 42 | - | [stripe] | |
| 43 | - | percent = 0.029 # US standard online card | |
| 44 | - | fixed = 0.30 # Per-transaction flat fee, USD | |
| 45 | - | dispute_fee = 15.00 # Charged once at dispute creation | |
| 46 | - | instant_payout_us_pct = 0.015 # US/AU/NZ/AE region (was incorrectly cited as flat 1%) | |
| 47 | - | instant_payout_intl_pct = 0.010 # CA/EU/UK/SG/NO/HK/MY region | |
| 48 | - | instant_payout_min = 0.50 | |
| 49 | - | chargeback_protection_pct = 0.004 # Stripe Radar add-on (fraud-only) | |
| 50 | - | tax_pct = 0.005 # Stripe Tax per transaction | |
| 51 | - | ||
| 52 | - | [stripe.connect_standard] | |
| 53 | - | # What MNW currently uses for creator subs. | |
| 54 | - | per_account_fee = 0 | |
| 55 | - | per_payout_fee = 0 | |
| 56 | - | payout_volume_pct = 0 | |
| 57 | - | ||
| 58 | - | [stripe.connect_express] | |
| 59 | - | # Reference only — not used by MNW for creators. | |
| 60 | - | per_active_account = 2.00 | |
| 61 | - | per_payout = 0.25 | |
| 62 | - | payout_volume_pct = 0.0025 | |
| 63 | - | ||
| 64 | - | ||
| 65 | - | # ─── Hetzner prices (canonical: hetzner_prices.md) ──────────────────────── | |
| 66 | - | [hetzner] | |
| 67 | - | fx_eur_to_usd = 1.085 # Verify when FX moves >5% | |
| 68 | - | ||
| 69 | - | # Compute SKUs (EUR/mo) | |
| 70 | - | ccx13_eur = 13.10 # 2 dedicated vCPU / 8 GB / 80 GB — production | |
| 71 | - | ccx23_eur = 30.00 # 4 dedicated vCPU / 16 GB / 160 GB | |
| 72 | - | cpx11_eur = 3.85 # 2 shared vCPU / 2 GB / 40 GB | |
| 73 | - | cpx31_eur = 13.10 # 4 shared vCPU / 8 GB / 160 GB | |
| 74 | - | cx22_eur = 4.59 # 2 shared vCPU / 4 GB / 40 GB | |
| 75 | - | ||
| 76 | - | # Storage and bandwidth | |
| 77 | - | object_storage_eur_per_tb = 5.99 | |
| 78 | - | object_storage_included_tb = 1 | |
| 79 | - | egress_eur_per_tb_overage = 1.00 | |
| 80 | - | egress_included_per_server_tb = 1 | |
| 81 | - | volume_eur_per_gb = 0.044 | |
| 82 | - | ipv4_eur = 0.60 | |
| 83 | - | backup_pct_of_server = 0.20 | |
| 84 | - | ||
| 85 | - | ||
| 86 | - | # ─── Tier prices (canonical: pricing.md) ────────────────────────────────── | |
| 87 | - | [tiers.founding] | |
| 88 | - | # Founder pricing — 50% of standard sticker, locked for life. Active until | |
| 89 | - | # the founder window closes (1,000 creators OR exit-beta, whichever first). | |
| 90 | - | # Decision 2026-05-18; see memory `project_founder_pricing.md`. | |
| 91 | - | basic = 5 | |
| 92 | - | small_files = 10 | |
| 93 | - | big_files = 15 | |
| 94 | - | everything = 30 | |
| 95 | - | ||
| 96 | - | [tiers.standard] | |
| 97 | - | # Post-founder sticker targets — NOT yet validated. The plan is to calibrate | |
| 98 | - | # the real post-founder rates from signup velocity, tier mix, and support | |
| 99 | - | # load observed during the founder window. Treat these as provisional upper | |
| 100 | - | # bounds, not committed prices. | |
| 101 | - | basic = 10 | |
| 102 | - | small_files = 20 | |
| 103 | - | big_files = 30 | |
| 104 | - | everything = 60 | |
| 105 | - | ||
| 106 | - | [annual_discount] | |
| 107 | - | # Annual billing is 10% off the monthly × 12 total at every tier, founder | |
| 108 | - | # and standard. Two-digit discount, clean pitch. Decision 2026-05-18. | |
| 109 | - | # | |
| 110 | - | # What this actually covers: | |
| 111 | - | # - Stripe per-transaction fees ($0.30 each, charged 12x for monthly vs 1x | |
| 112 | - | # for annual): saves MNW ~$3.30/yr per customer regardless of tier. | |
| 113 | - | # - The 2.9% percent fee is identical either way (a wash). | |
| 114 | - | # - At Basic, 10% off ≈ the literal Stripe saving (close to pass-through). | |
| 115 | - | # - At Everything, 10% off ($36/yr) > the Stripe saving ($3.30/yr); MNW | |
| 116 | - | # absorbs the difference (~$15/yr per Everything customer at founder | |
| 117 | - | # pricing, ~$32/yr per Everything customer at sticker) as a cashflow + | |
| 118 | - | # reduced-billing-failure benefit. Defensible but not pure pass-through. | |
| 119 | - | # | |
| 120 | - | # Computed values (monthly × 12 × 0.9, rounded to nearest dollar): | |
| 121 | - | # Founder: $54 / $108 / $162 / $324 | |
| 122 | - | # Standard: $108 / $216 / $324 / $648 | |
| 123 | - | multiplier = 0.9 | |
| 124 | - | months_equivalent_free = 1.2 # 10% of 12 months | |
| 125 | - | ||
| 126 | - | ||
| 127 | - | # ─── Tier mix (canonical: tier_mix.md) ──────────────────────────────────── | |
| 128 | - | [tier_mix.assumed] | |
| 129 | - | # Pre-launch placeholder distribution. A4 in assumptions.md. | |
| 130 | - | # Updated monthly from SQL once creators exist. | |
| 131 | - | basic_pct = 0.40 | |
| 132 | - | small_files_pct = 0.30 | |
| 133 | - | big_files_pct = 0.20 | |
| 134 | - | everything_pct = 0.10 | |
| 135 | - | ||
| 136 | - | ||
| 137 | - | # ─── Reserve policy (canonical: reserve_policy.md) ──────────────────────── | |
| 138 | - | [reserve] | |
| 139 | - | # OPEN: all values in this block per reserve_policy.md §8 | |
| 140 | - | ||
| 141 | - | T_fixed_months = 12 # OPEN: §8 item 1 | |
| 142 | - | S_legal = 50000 # OPEN: §8 item 2 — pre-quote | |
| 143 | - | S_shock = 5000 # OPEN: §8 item 3 | |
| 144 | - | ||
| 145 | - | R_opp = 10000 # OPEN: §8 item 4 | |
| 146 | - | rho_annual = 0.50 # OPEN: §8 item 5 — max % of R_opp/yr | |
| 147 | - | rho_incident = 0.25 # OPEN: §8 item 6 — max % of R_opp/decision | |
| 148 | - | ||
| 149 | - | surplus_split_reserve = 0.20 # OPEN: §8 item 7 — steady state | |
| 150 | - | surplus_split_earnback = 0.80 | |
| 151 | - | # Sum must equal 1.0 | |
| 152 | - | ||
| 153 | - | transition_buffer_pct = 1.00 # OPEN: §8 item 10 — multiplier on R_cap before personal-to-company transition | |
| 154 | - | ||
| 155 | - | ||
| 156 | - | # ─── Cohort (canonical: pricing.md) ─────────────────────────────────────── | |
| 157 | - | [cohort] | |
| 158 | - | # OPEN: all values per pricing.md §7 | |
| 159 | - | ||
| 160 | - | cap_count = 500 # OPEN: §7 item 1 — first N signups | |
| 161 | - | cap_months = 12 # OPEN: §7 item 1 — or first M months (whichever first) | |
| 162 | - | lock_duration = "lifetime" # OPEN: §7 item 4 — lifetime-of-subscription | |
| 163 | - | # Counting rule (cumulative vs active) — see sops/founding-cohort-tracking.md, founder decision pending | |
| 164 | - | ||
| 165 | - | ||
| 166 | - | # ─── Per-creator marginal cost inputs (canonical: assumptions.md A1-A10) ─ | |
| 167 | - | # All currently unmeasured — pre-launch placeholders. | |
| 168 | - | [creator_marginal] | |
| 169 | - | storage_basic_gb = 0.1 # A1: ~100 MB | |
| 170 | - | storage_small_files_gb = 2 # A2: ~2 GB | |
| 171 | - | storage_big_files_gb = 10 # A3: ~10 GB | |
| 172 | - | storage_everything_gb = 30 # A10: tier-dependent, placeholder | |
| 173 | - | storage_cost_per_gb_per_month = 0.0065 # = €5.99/TB-mo × FX | |
| 174 | - | egress_origin_hit_assumed_pct = 0.10 # A6: Cloudflare cache absorbs ~90% (assumed) | |
| 175 | - | chargeback_rate_tier_subs = 0.001 # A12: 0.1% for recurring (lower than one-shot) | |
| 176 | - | ||
| 177 | - | ||
| 178 | - | # ─── Derived values (for docengine feature; NOT stored — computed) ──────── | |
| 179 | - | # | |
| 180 | - | # These are documented here for the future implementation. The docengine | |
| 181 | - | # feature should compute them from the values above. Listed as commented | |
| 182 | - | # pseudo-code; actual implementation belongs in Rust. | |
| 183 | - | # | |
| 184 | - | # R_cap = T_fixed_months · F_monthly + S_legal + S_shock | |
| 185 | - | # = 12 · 580 + 50000 + 5000 = 61960 | |
| 186 | - | # | |
| 187 | - | # ARPU_founding = Σ (tier_mix[k] · tiers.founding[k]) | |
| 188 | - | # = 0.4·5 + 0.3·10 + 0.2·15 + 0.1·30 = 11.00 | |
| 189 | - | # | |
| 190 | - | # ARPU_standard = Σ (tier_mix[k] · tiers.standard[k]) | |
| 191 | - | # = 0.4·10 + 0.3·20 + 0.2·30 + 0.1·60 = 22.00 | |
| 192 | - | # | |
| 193 | - | # stripe_fee(amount) = stripe.percent · amount + stripe.fixed | |
| 194 | - | # stripe_fee_basic_std = 0.029 · 10 + 0.30 = 0.59 | |
| 195 | - | # stripe_fee_small_std = 0.029 · 20 + 0.30 = 0.88 | |
| 196 | - | # stripe_fee_big_std = 0.029 · 30 + 0.30 = 1.17 | |
| 197 | - | # stripe_fee_ev_std = 0.029 · 60 + 0.30 = 2.04 | |
| 198 | - | # | |
| 199 | - | # break_even(rate_class) = F_monthly / (ARPU_{rate_class} − marginal_avg) | |
| 200 | - | # break_even_standard = 580 / (22 − 1) ≈ 27.6 creators | |
| 201 | - | # break_even_founding = 580 / (11 − 1) ≈ 58 creators | |
| 202 | - | # | |
| 203 | - | # surplus(N, rate_class) = N · (ARPU − marginal) − F_monthly | |
| 204 | - | # surplus(100, "standard") = 100 · 21 − 580 = 1520 | |
| 205 | - | # surplus(500, "standard") = 500 · 21 − 580 = 9920 | |
| 206 | - | # | |
| 207 | - | # fill_time_months(N) = (R_cap + R_opp) / surplus(N, "standard") | |
| 208 | - | # fill_time(100) = 71960 / 1520 ≈ 47 mo | |
| 209 | - | # fill_time(500) = 71960 / 9920 ≈ 7 mo | |
| 210 | - | # | |
| 211 | - | # infra_cost(tier, N) = storage_{tier}_gb · storage_cost_per_gb_per_month | |
| 212 | - | # + egress_share + stripe_fee(price) + F_monthly/N | |
| 213 | - | # | |
| 214 | - | # Validation rules the build step should enforce: | |
| 215 | - | # - 100 < F_monthly < 10000 (typo guard) | |
| 216 | - | # - sum(tier_mix.*) = 1.00 (tier mix must sum to 100%) | |
| 217 | - | # - surplus_split_reserve + surplus_split_earnback = 1.00 | |
| 218 | - | # - 0 < rho_annual ≤ 1 | |
| 219 | - | # - 0 < rho_incident ≤ 1 | |
| 220 | - | # - rho_incident ≤ rho_annual (single decision ≤ annual budget) | |
| 221 | - | # - All `tiers.founding[k]` ≤ `tiers.standard[k]` | |
| 222 | - | # - cap_count > 0, cap_months > 0 |
| @@ -1,483 +0,0 @@ | |||
| 1 | - | # Business Sustainability Audit | |
| 2 | - | ||
| 3 | - | Run 1, 2026-04-29. Full audit of profitability, unit economics, and long-term viability. | |
| 4 | - | ||
| 5 | - | --- | |
| 6 | - | ||
| 7 | - | ## Overall Assessment | |
| 8 | - | ||
| 9 | - | MNW is a sound bootstrapped business at modest scale (100-500 creators). The financial model is internally consistent, transparently documented, and structurally viable. Stripe Connect Standard accounts eliminate the per-account fee drag that would have compressed margins on successful creators. | |
| 10 | - | ||
| 11 | - | **Strengths:** lean cost structure (~$580/mo fixed per `expenses.md`); honest economics with no value-extraction model; bounded reserves designed to absorb shocks without raising prices. | |
| 12 | - | ||
| 13 | - | **Constraints:** narrow addressable market; single-operator ceiling without the residency hiring pipeline. | |
| 14 | - | ||
| 15 | - | --- | |
| 16 | - | ||
| 17 | - | ## Ecosystem Context | |
| 18 | - | ||
| 19 | - | MNW is not a single product — it is an ecosystem of 13 interconnected projects. Server: ~88K LOC, 1,935 tests (run `tokei` + `cargo test -- --list` to refresh). | |
| 20 | - | ||
| 21 | - | ### Product Surface | |
| 22 | - | ||
| 23 | - | | Product | What it is | Revenue role | | |
| 24 | - | |---------|-----------|-------------| | |
| 25 | - | | **MNW Server** | Creator platform, SyncKit server, OTA server, OAuth provider, git host, issue tracker | Primary revenue (creator subscriptions) | | |
| 26 | - | | **Multithreaded** | Forum software (MNW OAuth, per-project communities) | Community stickiness, retention | | |
| 27 | - | | **PoM** | Production ops monitor (peer mesh, health checks, alerts) | Operational reliability | | |
| 28 | - | | **GoingsOn** | Productivity app (tasks, email, calendar, contacts) | SyncKit add-on revenue (planned) | | |
| 29 | - | | **Balanced Breakfast** | Feed aggregator (RSS, Atom, plugins) | SyncKit add-on revenue (planned) | | |
| 30 | - | | **audiofiles** | Sample manager (content-addressed, ML classification) | License key sales, SyncKit add-on | | |
| 31 | - | | **SyncKit SDK** | E2E encrypted cloud sync + OTA updates | Add-on revenue (planned) | | |
| 32 | - | | **Shared libraries** | docengine, tagtree, theme-common, s3-storage, tauri-updater-ui | Shared infrastructure cost | | |
| 33 | - | ||
| 34 | - | The three desktop apps (GO, BB, AF) are both products and dogfood for SyncKit. They generate direct revenue through the MNW storefront (license keys, purchases, subscriptions) and demonstrate the platform to potential creator-developers. | |
| 35 | - | ||
| 36 | - | ### How they connect | |
| 37 | - | ||
| 38 | - | ``` | |
| 39 | - | ┌─────────────────────┐ | |
| 40 | - | │ MNW Server │ | |
| 41 | - | │ (creator platform │ | |
| 42 | - | │ + SyncKit server │ | |
| 43 | - | │ + OTA server │ | |
| 44 | - | │ + OAuth provider) │ | |
| 45 | - | └──┬──────┬──────┬────┘ | |
| 46 | - | │ │ │ | |
| 47 | - | OAuth │ Sync│ OTA │ | |
| 48 | - | PKCE │ API │ API │ | |
| 49 | - | │ │ │ | |
| 50 | - | ┌────────────┤ │ ├────────────┐ | |
| 51 | - | │ │ │ │ │ | |
| 52 | - | ┌─────▼──┐ ┌─────▼──┐ │ ┌───▼────┐ ┌───▼────┐ | |
| 53 | - | │ MT │ │ GO │ │ │ BB │ │ AF │ | |
| 54 | - | │(forums)│ │(tasks) │ │ │(feeds) │ │(audio) │ | |
| 55 | - | └────────┘ └────────┘ │ └────────┘ └────────┘ | |
| 56 | - | │ │ │ │ | |
| 57 | - | └──────┼───────┘ │ | |
| 58 | - | │ │ | |
| 59 | - | ┌────────▼────────┐ │ | |
| 60 | - | │ synckit-client │◄──────────┘ | |
| 61 | - | │ (shared SDK) │ | |
| 62 | - | └─────────────────┘ | |
| 63 | - | ||
| 64 | - | ┌──────────┐ | |
| 65 | - | │ PoM │──── monitors ──── MNW, MT, htpy.app | |
| 66 | - | │(monitor) │ | |
| 67 | - | └──────────┘ | |
| 68 | - | ``` | |
| 69 | - | ||
| 70 | - | This ecosystem structure matters for the business model because: | |
| 71 | - | - **Shared libraries reduce maintenance cost** — docengine, tagtree, and theme-common are used across 4+ projects each | |
| 72 | - | - **SyncKit is both infrastructure and product** — a single investment serves internal apps and becomes an add-on revenue stream | |
| 73 | - | - **Desktop apps are both revenue and marketing** — creators see the platform in action via real products | |
| 74 | - | - **MT provides community without external dependency** — no Discourse/Circle subscription cost | |
| 75 | - | ||
| 76 | - | --- | |
| 77 | - | ||
| 78 | - | ## Infrastructure and Operations | |
| 79 | - | ||
| 80 | - | ### Physical infrastructure | |
| 81 | - | ||
| 82 | - | | Host | IP | Runs | Cost | | |
| 83 | - | |------|----|------|------| | |
| 84 | - | | **Hetzner VPS** (US-West) | Public: 5.78.144.244, Tailscale: 100.120.174.96 | MNW, MT, PostgreSQL, Caddy, PoM, Git SSH | $31/month (per expenses.md) | | |
| 85 | - | | **Astra** (dev/CI) | Tailscale: 100.106.221.39 | PoM, CI runner, staging, backup replication | Personal hardware (no recurring cost) | | |
| 86 | - | | **Hetzner S3** | fsn1 region | File uploads, SyncKit blobs | $5.99/month (per expenses.md) | | |
| 87 | - | ||
| 88 | - | All access via Tailscale mesh. No Docker — native binaries with systemd units. Cross-compiled on macOS with cargo-zigbuild. | |
| 89 | - | ||
| 90 | - | ### Service dependencies and costs | |
| 91 | - | ||
| 92 | - | | Service | Role | Monthly cost | Risk if lost | | |
| 93 | - | |---------|------|-------------|-------------| | |
| 94 | - | | **Stripe** | Payments (Connect Standard) | ~3% of platform subs only | Fatal — no alternative processor integrated | | |
| 95 | - | | **Postmark** | Transactional + broadcast email | $0 actual (per expenses.md) | Degraded — can queue, self-host later | | |
| 96 | - | | **Cloudflare** | CDN, DNS, DDoS, TLS | $0 (free tier) | High — origin egress costs spike | | |
| 97 | - | | **Hetzner** | VPS + S3 | $31 + $5.99 (per expenses.md) | Can migrate — standard S3 API, portable binary | | |
| 98 | - | | **Apple Developer** | macOS code signing + notarization | ~$99/year | App distribution blocked (not server) | | |
| 99 | - | ||
| 100 | - | Total: **$580/month** currently (per expenses.md). All vendors are commodity-replaceable except Stripe. | |
| 101 | - | ||
| 102 | - | ### Credential inventory | |
| 103 | - | ||
| 104 | - | 15 env vars required for full production (DATABASE_URL, SIGNING_SECRET, HOST_URL, STRIPE_*, POSTMARK_*, S3_*). 8 optional (SyncKit S3, CDN, scanning, build pipeline). All secrets on Hetzner at `/opt/makenotwork/.env`. Rotation procedures documented per-credential in `_meta/docs/service_accounts.md`. | |
| 105 | - | ||
| 106 | - | ### Deploy pipeline | |
| 107 | - | ||
| 108 | - | ``` | |
| 109 | - | MacBook (macOS) | |
| 110 | - | → cargo zigbuild --release (x86_64-linux-gnu) | |
| 111 | - | → rsync binary + static assets + config → Hetzner | |
| 112 | - | → systemctl restart makenotwork | |
| 113 | - | → curl localhost:3000/api/health | |
| 114 | - | ``` | |
| 115 | - | ||
| 116 | - | Three deploy modes: full (build + config + binary), quick (binary only), config-only. Rollback: re-deploy previous binary. No blue-green, no canary — single server, single binary. | |
| 117 | - | ||
| 118 | - | ### Monitoring | |
| 119 | - | ||
| 120 | - | Two PoM instances (Hetzner + Astra) cross-check each other. Health endpoint at `/api/health` checks: database connectivity, S3 availability, Stripe webhook liveness, email deliverability, background scheduler health. Email alerts on status transitions. MNW internal background monitor runs health checks every 60 seconds. | |
| 121 | - | ||
| 122 | - | ### Incident response | |
| 123 | - | ||
| 124 | - | | Level | Description | Response time | | |
| 125 | - | |-------|-------------|---------------| | |
| 126 | - | | P0 | Service down, data loss risk | Immediate | | |
| 127 | - | | P1 | Major feature broken (payments, sync, auth) | < 1 hour | | |
| 128 | - | | P2 | Degraded but functional | < 4 hours | | |
| 129 | - | | P3 | Minor issue | Next working session | | |
| 130 | - | ||
| 131 | - | Single contact point: Max. Credential rotation checklist covers all 12 credential types. Server auto-restarts via systemd on crash. | |
| 132 | - | ||
| 133 | - | ### Backups | |
| 134 | - | ||
| 135 | - | - PostgreSQL: daily automated backups, 30-day retention, `/opt/makenotwork/backups/` on Hetzner | |
| 136 | - | - Offsite replication: daily rsync to Astra at `/opt/backups/mnw/` | |
| 137 | - | - S3: bucket versioning enabled | |
| 138 | - | - PoM monitors backup staleness | |
| 139 | - | ||
| 140 | - | --- | |
| 141 | - | ||
| 142 | - | ## Operational Scaling Model | |
| 143 | - | ||
| 144 | - | ### The residency program as a scaling strategy | |
| 145 | - | ||
| 146 | - | MNW's hiring model is documented in `_meta/docs/residency.md` and `_meta/docs/operations.md`. It is not a standard hire — it's a structured apprenticeship: | |
| 147 | - | ||
| 148 | - | - **Who**: Exceptionally smart people lacking programming experience (often leaving academia) | |
| 149 | - | - **Compensation**: Starting ~$70K, +$10K/year fixed raises, same scale as founder | |
| 150 | - | - **Duration**: Fluid, typically 3-4 years | |
| 151 | - | - **Goal**: Graduation into independent full-stack engineer, not retention | |
| 152 | - | ||
| 153 | - | This matters for business sustainability because: | |
| 154 | - | 1. **Lower initial labor cost** than hiring senior engineers | |
| 155 | - | 2. **Residents produce real work from day one** (customer support → features → architecture) | |
| 156 | - | 3. **Knowledge transfer is built into the model** — familiarization checklist is 7 phases covering all 13 projects | |
| 157 | - | 4. **Alumni network creates long-term value** — graduated residents in industry positions extend MNW's reach | |
| 158 | - | ||
| 159 | - | ### Trust ladder and operational capacity | |
| 160 | - | ||
| 161 | - | The operations model uses a four-level trust progression: | |
| 162 | - | ||
| 163 | - | | Level | Role | Operational capacity added | | |
| 164 | - | |-------|------|--------------------------| | |
| 165 | - | | L1 — Patch Contributor | Submit patches, reviewed before merge | Reduces founder's bug-fix backlog | | |
| 166 | - | | L2 — Trusted Contributor | Self-merge trivial fixes | Reduces review burden | | |
| 167 | - | | L3 — Area Owner | Own a subsystem, review others' patches | Founder can delegate entire areas | | |
| 168 | - | | L4 — Senior Resident | Full merge rights, trains others, writes changelog | Founder focuses on strategy | | |
| 169 | - | ||
| 170 | - | **Business impact**: Each trust level crossed reduces the founder's operational load. | |
| 171 | - | ||
| 172 | - | ### Development cycle | |
| 173 | - | ||
| 174 | - | Four-week cycle: 2-week merge window (features, refactors) + 2-week stabilization (bugs, tests, docs, release). No-regressions rule: any change that breaks a test is reverted immediately, no exceptions. Deploy at end of week 4. Changelog published same day as release. | |
| 175 | - | ||
| 176 | - | This cycle is relevant to sustainability because it means: | |
| 177 | - | - **Feature velocity is predictable** — 6 merge windows per quarter | |
| 178 | - | - **Quality is enforced structurally** — stabilization prevents release-day surprises | |
| 179 | - | - **The cycle works at any team size** — one person or ten people, same rhythm | |
| 180 | - | ||
| 181 | - | ### Staffing cost projections | |
| 182 | - | ||
| 183 | - | | Stage | Headcount | Monthly labor cost | Creator threshold | | |
| 184 | - | |-------|-----------|-------------------|-------------------| | |
| 185 | - | | Current (founder only) | 1 | $0 (personal savings) | 0-100 creators | | |
| 186 | - | | Part-time support | 1.5 | $600-1,200 | ~100 creators | | |
| 187 | - | | First resident | 2 | $5,800 (~$70K/yr) | ~200 creators | | |
| 188 | - | | Founder salary + resident | 2 | $11,600 ($140K combined) | ~300 creators ($9,700 surplus at 500) | | |
| 189 | - | | Two residents + founder | 3 | $17,400 ($210K combined) | ~500+ creators | | |
| 190 | - | ||
| 191 | - | At 500 creators with ~$9,700/month surplus: covers founder ($5,800) + one resident ($5,800) with $2,100/month for infrastructure, reserves, and development. The model works — but only at 500+ creators with good tier mix. | |
| 192 | - | ||
| 193 | - | --- | |
| 194 | - | ||
| 195 | - | ## Business Model Map | |
| 196 | - | ||
| 197 | - | ### What does the business sell? | |
| 198 | - | ||
| 199 | - | Monthly creator subscriptions ($10-60) tiered by content type. 0% platform fee on fan payments. Fan+ consumer subscriptions ($8/month with $5 monthly credit). Planned add-ons for SyncKit cloud sync, automated email, and DSP distribution. | |
| 200 | - | ||
| 201 | - | ### Revenue streams | |
| 202 | - | ||
| 203 | - | | Stream | Pricing | Who pays | Status | | |
| 204 | - | |--------|---------|----------|--------| | |
| 205 | - | | Creator subscriptions | $10-60/month flat | Creators | Live | | |
| 206 | - | | Fan+ subscriptions | $8/month ($5 credit back) | Fans | Planned (pre-beta priority) | | |
| 207 | - | | SyncKit cloud sync | TBD add-on | Developers | Planned | | |
| 208 | - | | Automated email (Postmark) | TBD add-on | Creators | Planned | | |
| 209 | - | | DSP distribution | $10-15/month add-on | Music creators | Planned | | |
| 210 | - | ||
| 211 | - | ### Cost structure | |
| 212 | - | ||
| 213 | - | | Cost | Type | Current | Scales with | | |
| 214 | - | |------|------|---------|-------------| | |
| 215 | - | | Infrastructure (servers, DB, storage, DNS) | Fixed | $580/month (per expenses.md) | Creator count (sub-linear) | | |
| 216 | - | | Storage (Hetzner S3) | Variable | $0.10-3.00/creator | Upload volume | | |
| 217 | - | | CDN/bandwidth (Cloudflare + Hetzner) | Variable | $0.20-2.50/creator | Download volume | | |
| 218 | - | | Email (Postmark) | Variable | ~$0.40-0.80/creator | Follower count, broadcast frequency | | |
| 219 | - | | Stripe processing (platform subs only) | Variable | ~3% of subscription | Creator count | | |
| 220 | - | | Malware scanning | Fixed/Variable | Near $0 (ClamAV self-hosted) | Upload volume | | |
| 221 | - | ||
| 222 | - | Stripe Connect Standard accounts: no per-account fees, no payout-volume fees, no per-payout fees to the platform. Creators pay Stripe's standard processing (~2.9% + $0.30) directly from their own connected accounts. | |
| 223 | - | ||
| 224 | - | ### Key assumptions | |
| 225 | - | ||
| 226 | - | 1. Creator count grows to 32+ (break-even) within 12-18 months | |
| 227 | - | 2. Tier mix stays roughly distributed (not all-Basic) | |
| 228 | - | 3. Cloudflare free tier remains available for CDN | |
| 229 | - | 4. Stripe doesn't significantly raise processing fees | |
| 230 | - | 5. One person can operate the platform until revenue supports hiring | |
| 231 | - | ||
| 232 | - | --- | |
| 233 | - | ||
| 234 | - | ## Unit Economics | |
| 235 | - | ||
| 236 | - | ### Per-Creator Margins (Stripe Connect Standard — no Connect fees) | |
| 237 | - | ||
| 238 | - | | Tier | Price | Variable Cost | Margin | | |
| 239 | - | |------|-------|---------------|--------| | |
| 240 | - | | Basic | $10/mo | $0.85-1.90 | $8.10-9.15 | | |
| 241 | - | | Small Files | $20/mo | $1.90-3.80 | $16.20-18.10 | | |
| 242 | - | | Big Files | $30/mo | $3.60-8.60 | $21.40-26.40 | | |
| 243 | - | | Everything | $60/mo | $5.00-9.70 | $50.30-55.00 | | |
| 244 | - | ||
| 245 | - | ### Break-Even | |
| 246 | - | ||
| 247 | - | | Tier Mix | Avg Margin | Creators Needed | | |
| 248 | - | |----------|------------|-----------------| | |
| 249 | - | | Basic-heavy | ~$8.50 | ~70 | | |
| 250 | - | | Audio-heavy | ~$17.00 | ~35 | | |
| 251 | - | | Video-heavy | ~$24.00 | ~25 | | |
| 252 | - | | Mixed (realistic) | ~$19.00 | ~32 | | |
| 253 | - | ||
| 254 | - | ### Scale Projections | |
| 255 | - | ||
| 256 | - | | Scale | Fixed | Variable | Total Cost | Revenue | Surplus | | |
| 257 | - | |-------|-------|----------|------------|---------|---------| | |
| 258 | - | | 100 creators | $600 | $300 | $900 | $2,400 | $1,500 | | |
| 259 | - | | 500 creators | $800 | $1,500 | $2,300 | $12,000 | $9,700 | | |
| 260 | - | | 2,000 creators | $1,500 | $6,000 | $7,500 | $48,000 | $40,500 | | |
| 261 | - | ||
| 262 | - | ### Fan+ Unit Economics | |
| 263 | - | ||
| 264 | - | | Line | Amount | | |
| 265 | - | |------|--------| | |
| 266 | - | | Fan pays | $8.00 | | |
| 267 | - | | Stripe processing | -$0.53 (2.9% + $0.30 per stripe_fees.md) | | |
| 268 | - | | $5 credit issued | -$5.00 | | |
| 269 | - | | MNW net per subscriber | $2.47 | | |
| 270 | - | ||
| 271 | - | At 100 subscribers: $247/month. At 500: $1,235/month. Credit expires monthly (no rollover). If unredeemed, MNW nets $7.47 instead. | |
| 272 | - | ||
| 273 | - | ### Verdict: Sustainable | |
| 274 | - | ||
| 275 | - | Positive gross margin at all tiers. No Connect fee drag. Break-even at 32 creators is achievable. The model works at modest scale without requiring aggressive growth. | |
| 276 | - | ||
| 277 | - | --- | |
| 278 | - | ||
| 279 | - | ## Critical Risks | |
| 280 | - | ||
| 281 | - | ### 1. One-person operation is a hard ceiling at ~500 creators | |
| 282 | - | ||
| 283 | - | - **Where**: economics.md, guarantees.md, `_meta/docs/operations.md` | |
| 284 | - | - **Impact**: At high creator counts, workload across development, support, moderation, operations, and business exceeds what a single operator can sustain. Support response times degrade first, followed by moderation queue backup, then feature velocity collapse. The deploy pipeline is manual (MacBook → rsync → Hetzner), incident response has a single contact point, and the four-week development cycle has no slack for unplanned work during stabilization. | |
| 285 | - | - **Mitigation**: The residency model (`_meta/docs/residency.md`) is designed for this. First resident starts at ~$70K/year (~$5,800/month), which the platform can fund at ~300 creators. Part-time support hire (~$600-1,200/month) should come earlier at ~100 creators. The trust ladder means a resident producing value within weeks (L1 patches, customer support), not months. Added to todo.md. | |
| 286 | - | ||
| 287 | - | ### 2. No growth mechanism beyond word-of-mouth | |
| 288 | - | ||
| 289 | - | - **Where**: outreach/tiers.md, outreach/budget.md | |
| 290 | - | - **Impact**: MNW explicitly rejects algorithmic discovery, paid acquisition, and network effects. Growth depends on organic outreach to creators already frustrated with their current platform. Outreach doc lists ~425 target creators (128 high-fit) with a ~$1,455/year budget. | |
| 291 | - | - **Mitigation**: This is a deliberate design choice. The pitch stands on two pillars: (1) cheaper at scale and (2) intentionally resistant to enshittification. Timeline to "comfortable" (~$5K/month surplus at ~295 creators) is measured in years. Acceptable for a bootstrapped lifestyle business. The desktop apps (GO, BB, AF) serve as organic marketing — developers who use them encounter the MNW platform. | |
| 292 | - | ||
| 293 | - | ### 3. Addressable market is structurally limited | |
| 294 | - | ||
| 295 | - | - **Where**: pricing calculator, competitive analysis | |
| 296 | - | - **Impact**: Below ~$400/month in fan revenue, MNW is more expensive than Ko-fi Free (0% on tips, 5% on shop) or Bandcamp (15%). MNW only saves creators money above the crossover point. This limits the market to the top 5-10% of platform creators globally. | |
| 297 | - | - **Mitigation**: Intentional. Earn-Back Credit (added to todo.md, ship before beta) softens the barrier for low-earning creators. The platform targets creators who earn enough that flat fees save money. | |
| 298 | - | ||
| 299 | - | ### 4. Stripe is a single point of failure for payments | |
| 300 | - | ||
| 301 | - | - **Where**: `_meta/docs/service_accounts.md`, payment-independence.md | |
| 302 | - | - **Impact**: All payment processing — creator subscriptions, fan purchases, Fan+ — runs through Stripe. If Stripe suspends the platform account, terminates Connect access, or significantly raises fees, there is no fallback processor. | |
| 303 | - | - **Mitigation**: Payment independence is on the roadmap (Phase 24 in todo.md). The architecture uses direct charges on connected accounts, so creators keep their own Stripe accounts if they leave. Short-term risk is low (Stripe is stable), but it is the most dangerous vendor dependency. | |
| 304 | - | ||
| 305 | - | --- | |
| 306 | - | ||
| 307 | - | ## Pricing Assessment | |
| 308 | - | ||
| 309 | - | ### Verified Against Code | |
| 310 | - | ||
| 311 | - | All documented prices match code exactly: | |
| 312 | - | - Tier prices: `enums.rs:505-512` (`price_cents()`) | |
| 313 | - | - Storage limits: `enums.rs:525-531` (`max_storage_bytes()`) | |
| 314 | - | - File limits: `enums.rs:515-522` (`max_file_bytes()`) | |
| 315 | - | - 0% platform fee: `checkout.rs` — `application_fee_amount` omitted; `platform_fee_cents: Cents::ZERO` in all transactions | |
| 316 | - | ||
| 317 | - | ### Pricing Problems | |
| 318 | - | ||
| 319 | - | 1. **Everything tier ($60) is blocked in code** — returns "not yet available." Raised from $40 to $60 to reflect live streaming infrastructure. Clear differentiation from Big Files: streaming + 0% donation fees + all future features. Unblock when MediaMTX integration is ready. | |
| 320 | - | ||
| 321 | - | 2. **Earn-Back Credit documented but not implemented** — Internal economics.md presented it as current policy; how-we-work.md correctly marks "Planned." Added to todo.md for pre-beta implementation. Counter on pricing page will serve as signup incentive. | |
| 322 | - | ||
| 323 | - | 3. **Pricing calculator Ko-fi entry was inaccurate** — Fixed. Now reads "0% tips, 5% shop/memberships + ~3%" (was "5% shop + ~3%"). All 9 competitors verified against current public pricing pages. | |
| 324 | - | ||
| 325 | - | ### Revenue Crossover Points (MNW becomes cheaper than competitor) | |
| 326 | - | ||
| 327 | - | | vs Competitor | Crossover (Basic $10/mo) | | |
| 328 | - | |--------------|--------------------------| | |
| 329 | - | | Ko-fi Free (5% shop) | ~$200/mo fan revenue | | |
| 330 | - | | Bandcamp (15%) | ~$67/mo fan revenue | | |
| 331 | - | | Patreon (10%) | ~$100/mo fan revenue | | |
| 332 | - | | Gumroad (10% + $0.50/tx) | ~$100/mo fan revenue | | |
| 333 | - | ||
| 334 | - | --- | |
| 335 | - | ||
| 336 | - | ## Cost Risks | |
| 337 | - | ||
| 338 | - | ### 1. Bandwidth egress if Cloudflare becomes unavailable | |
| 339 | - | ||
| 340 | - | - **Trigger**: Cloudflare account termination, policy change, or free-tier degradation | |
| 341 | - | - **Impact**: Hetzner S3 egress at ~$1/TB. A viral 500MB album with 10,000 downloads = 5TB = ~$5 | |
| 342 | - | - **Mitigation**: Cloudflare caching reduces origin pulls to near-zero. Hetzner presigned URL fallback documented. Budget $200-500/month reserve at 500+ creators. | |
| 343 | - | ||
| 344 | - | ### 2. Video transcoding costs when feature ships | |
| 345 | - | ||
| 346 | - | - **Trigger**: Big Files "automatic transcoding" is "(planned)" in tiers.md. Full transcoding pipeline is documented in todo.md Phase 14E (5 sub-phases: probe, audio transcode, format choice, video transcode, adaptive streaming). | |
| 347 | - | - **Impact**: Estimated $2.70-5.40 per hour of video (AWS MediaConvert). Weekly video creator = $10-22/month against $30 subscription. Storage multiplication (original + 3 quality tiers) adds 4x per source file. | |
| 348 | - | - **Mitigation**: Feature isn't built yet. Phase 14E is post-beta. Consider making transcoding an add-on or rate-limiting encodes per tier when it ships. | |
| 349 | - | ||
| 350 | - | ### 3. Email costs at scale with high-follower creators | |
| 351 | - | ||
| 352 | - | - **Trigger**: Creator with 50,000 followers doing monthly broadcasts = 50,000 emails = ~$25 via Postmark | |
| 353 | - | - **Impact**: Tech_costs.md budgets $0.40-0.80/creator for email. High-follower creator exceeds this 30x. | |
| 354 | - | - **Mitigation**: Per-creator email cost tracking. Self-hosted email planned (Phase 18 in todo.md, trigger: >50 creators, Postmark >$50/month). Broadcast emails use separate Postmark stream. | |
| 355 | - | ||
| 356 | - | ### 4. Content Archive guarantee creates indefinite storage liability | |
| 357 | - | ||
| 358 | - | - **Trigger**: Planned guarantee to host content 12+ months after cancellation | |
| 359 | - | - **Impact**: Cancelled creator's 500GB costs ~$3.35/month forever at Hetzner S3 rates | |
| 360 | - | - **Mitigation**: Not yet implemented. Consider a retention cap (e.g., 2 years) or fund from reserves. | |
| 361 | - | ||
| 362 | - | --- | |
| 363 | - | ||
| 364 | - | ## Revenue Gaps | |
| 365 | - | ||
| 366 | - | | Gap | Opportunity | Complexity | Status | | |
| 367 | - | |-----|------------|------------|--------| | |
| 368 | - | | Fan+ not live | $247-2,470/month at 100-1,000 subs | Easy (fully designed) | Pre-beta priority | | |
| 369 | - | | No add-on revenue | DSP alone could add $950-2,000/month at 500 creators | Moderate (vendor relationship) | Planned (Phase 23, trigger: >100 music creators) | | |
| 370 | - | | No enterprise/team tier | $100-200/month covering 5-10 creator seats | Moderate | Not planned | | |
| 371 | - | | Earn-Back Credit not implemented | Signup incentive, reduces churn for low-earners | Easy-moderate | Pre-beta priority | | |
| 372 | - | | SyncKit not productized | Cloud sync add-on for indie developers | Moderate (Phase S9 in todo.md) | Infrastructure built, pricing TBD | | |
| 373 | - | ||
| 374 | - | --- | |
| 375 | - | ||
| 376 | - | ## Scaling Bottlenecks | |
| 377 | - | ||
| 378 | - | ### Technical | |
| 379 | - | ||
| 380 | - | | Bottleneck | Current Capacity | Break Point | Fix | | |
| 381 | - | |------------|------------------|-------------|-----| | |
| 382 | - | | Database pool (25 connections) | ~200 concurrent users | 500+ creators | Increase pool, add PgBouncer | | |
| 383 | - | | File scanning (4 concurrent, 100MB RAM each) | 50 creators uploading weekly | 50+ concurrent uploads | Async scanning (background queue in todo.md) | | |
| 384 | - | | Email (single-request Postmark API) | 50,000 emails/week | 500+ creators broadcasting | Batch Postmark API | | |
| 385 | - | | Single VPS (all services on one machine) | unmeasured | Viral spike | Load balancer + 2nd VPS (~$20/month) | | |
| 386 | - | | In-memory session cache (DashMap) | Single server only | Horizontal scaling | Accept cache misses on horizontal scale | | |
| 387 | - | | Rate limiting (per-IP only) | Normal traffic | Botnet abuse | Add per-creator rate limits | | |
| 388 | - | ||
| 389 | - | ### Operational | |
| 390 | - | ||
| 391 | - | | Bottleneck | Current Capacity | Break Point | Fix | | |
| 392 | - | |------------|------------------|-------------|-----| | |
| 393 | - | | Single operator (all roles) | ~100 creators | 500+ (70 hrs/week) | Part-time support at 100, first resident at 200 | | |
| 394 | - | | Manual deploy (MacBook → rsync) | Founder only | Founder unavailable | CI pipeline on Astra (partially built) | | |
| 395 | - | | Manual moderation (no triage) | 10-20 issues/day | 40+ issues/day | Auto-triage rules, SLA timers | | |
| 396 | - | | Manual creator onboarding | Founder reviews each application | 50+ applications/month | Semi-automated approval criteria | | |
| 397 | - | | Single incident responder | 24/7 founder availability | Founder unavailable | L3 resident with deploy access | | |
| 398 | - | ||
| 399 | - | --- | |
| 400 | - | ||
| 401 | - | ## Competitive Position | |
| 402 | - | ||
| 403 | - | ### Strengths | |
| 404 | - | ||
| 405 | - | 1. **0% platform fee is real and verified in code** — `application_fee_amount` omitted, `platform_fee_cents: Cents::ZERO` hardcoded | |
| 406 | - | 2. **Radical cost transparency** — public economics page with actual cost ranges, margins, break-even analysis | |
| 407 | - | 3. **Infrastructure cost discipline** — Hetzner over AWS saves ~80%, self-hosted PostgreSQL, Cloudflare free tier, no Docker overhead | |
| 408 | - | 4. **Direct-to-creator payments** — MNW never holds creator funds, no settlement risk | |
| 409 | - | 5. **Debt-free, self-funded** — no investor pressure, no creditors, personal savings runway | |
| 410 | - | 6. **Data portability backed by code** — export endpoints implemented, not vaporware | |
| 411 | - | 7. **Stripe Standard accounts** — no per-account Connect fees, margins don't compress with creator success | |
| 412 | - | 8. **Ecosystem depth** — 13 interconnected projects, shared libraries, integrated forums, built-in monitoring | |
| 413 | - | 9. **Source-available codebase** — every claim verifiable in code (PolyForm Noncommercial) | |
| 414 | - | 10. **Structured scaling path** — residency model, trust ladder, four-week cycle all documented and ready for first hire | |
| 415 | - | ||
| 416 | - | ### Vulnerabilities | |
| 417 | - | ||
| 418 | - | | Vulnerability | Severity | Defense | | |
| 419 | - | |---------------|----------|---------| | |
| 420 | - | | Ko-fi Free undercuts for <$400/month creators | Medium | Intentional — MNW targets $400+/month creators | | |
| 421 | - | | itch.io's 0% creator-chosen fee | Medium | Different feature set; itch.io payout instability | | |
| 422 | - | | No discovery = no new creator growth | High (structural) | Deliberate design choice; pitch on anti-enshittification | | |
| 423 | - | | VC-backed competitor at $5/month | Low | MNW's ~$580/month costs can outlast subsidized pricing | | |
| 424 | - | | Stripe dependency | Medium | Payment independence on roadmap (Phase 24) | | |
| 425 | - | ||
| 426 | - | --- | |
| 427 | - | ||
| 428 | - | ## Contradictions Found | |
| 429 | - | ||
| 430 | - | | Claim | Reality | Severity | Resolution | | |
| 431 | - | |-------|---------|----------|------------| | |
| 432 | - | | Earn-Back Credit (economics.md) presented as current | Not implemented, no schema | Medium | Added to todo.md pre-beta; mark "planned" consistently | | |
| 433 | - | | Content Archive in how-we-work.md | Correctly marked "planned" in guarantees.md but not elsewhere | Low | Consistent labeling needed | | |
| 434 | - | | ~~Stripe Express in 8 docs + code~~ | ~~Should be Standard~~ | ~~High~~ | Fixed in this session | | |
| 435 | - | | ~~Ko-fi Free "5% shop" in calculator~~ | ~~0% on tips, 5% on shop/memberships~~ | ~~Low-medium~~ | Fixed in this session | | |
| 436 | - | | `CREATOR_TIER_STREAMING_PRICE_ID` in service_accounts.md | Tier renamed to "Everything" (migration 079, 2026-04-27) | Low | Update service_accounts.md | | |
| 437 | - | ||
| 438 | - | --- | |
| 439 | - | ||
| 440 | - | ## Actions Taken (this session) | |
| 441 | - | ||
| 442 | - | - [x] Stripe Connect Express -> Standard: code (`connect.rs`), 8 docs, all cost tables, break-even numbers | |
| 443 | - | - [x] Pricing calculator: Ko-fi Free label corrected, all 9 competitors verified against current pricing | |
| 444 | - | - [x] Public economics page: per-creator costs updated, break-even corrected (36 -> 32), "low number" paragraph softened | |
| 445 | - | - [x] todo.md: Earn-Back Credit added (pre-beta priority), Fan+ bumped (pre-beta priority), churn monitoring added (future phase), support hire budget added | |
| 446 | - | ||
| 447 | - | ## Recommendations (prioritized) | |
| 448 | - | ||
| 449 | - | 1. **Ship Earn-Back Credit before beta** — reduces $120/year entry barrier, provides signup incentive counter on pricing page | |
| 450 | - | 2. **Ship Fan+ before beta** — creates spending flywheel, community stickiness, $2.47/subscriber revenue diversification | |
| 451 | - | 3. **Implement churn monitoring before 100 creators** — at 32 creators, losing 3 drops below break-even with no warning system | |
| 452 | - | 4. **Budget for part-time support hire at 100 creators** — ~$600-1,200/month prevents support quality collapse | |
| 453 | - | 5. **Define Everything tier before unblocking** — ship at least one exclusive feature to justify the $10 premium over Big Files | |
| 454 | - | 6. **Diversify the pitch** — lead with cheaper-at-scale economics and enshittification resistance, not competitor instability | |
| 455 | - | 7. **Productize SyncKit** — infrastructure is built and dogfooded by 3 apps; pricing and marketing are the gap (Phase S9) | |
| 456 | - | 8. **Fix stale `CREATOR_TIER_STREAMING_PRICE_ID`** in `_meta/docs/service_accounts.md` (renamed to Everything) | |
| 457 | - | ||
| 458 | - | --- | |
| 459 | - | ||
| 460 | - | ## Reference Documents | |
| 461 | - | ||
| 462 | - | ### Business and economics | |
| 463 | - | - [Platform Economics (public)](../../site-docs/public/about/economics.md) — what creators see | |
| 464 | - | - [Economics (internal)](./economics.md) — detailed cost model | |
| 465 | - | - [Financial Dashboard](./financial_dashboard.md) — consolidated financial view | |
| 466 | - | - [Tech Costs](../strategy/tech_costs.md) — line-item cost breakdown | |
| 467 | - | - [Payment Independence](./payment-independence.md) — Stripe dependency and alternatives | |
| 468 | - | - [Fan+](./fan-plus.md) — consumer subscription design | |
| 469 | - | ||
| 470 | - | ### Operations and infrastructure | |
| 471 | - | - [`_meta/docs/operations.md`](../../../../_meta/docs/operations.md) — development cycles, merge privileges, trust ladder | |
| 472 | - | - [`_meta/docs/residency.md`](../../../../_meta/docs/residency.md) — hiring model, compensation, progression | |
| 473 | - | - [`_meta/docs/incident_response.md`](../../../../_meta/docs/incident_response.md) — severity levels, response checklists, credential rotation | |
| 474 | - | - [`_meta/docs/service_accounts.md`](../../../../_meta/docs/service_accounts.md) — credential inventory, rotation procedures | |
| 475 | - | - [`_meta/ecosystem.md`](../../../../_meta/ecosystem.md) — 13-project ecosystem map, connections, test counts | |
| 476 | - | - [`_meta/docs/familiarization_checklist.md`](../../../../_meta/docs/familiarization_checklist.md) — onboarding plan for new team members | |
| 477 | - | ||
| 478 | - | ### Infrastructure diagrams | |
| 479 | - | - [`_meta/diagrams/infra/network_topology.md`](../../../../_meta/diagrams/infra/network_topology.md) — physical infrastructure, DNS, Tailscale mesh | |
| 480 | - | - [`_meta/diagrams/infra/deploy_pipeline.md`](../../../../_meta/diagrams/infra/deploy_pipeline.md) — build, upload, restart for each service | |
| 481 | - | - [`_meta/diagrams/infra/server_architecture.md`](../../../../_meta/diagrams/infra/server_architecture.md) — MNW server internals | |
| 482 | - | - [`_meta/diagrams/infra/external_services.md`](../../../../_meta/diagrams/infra/external_services.md) — third-party integrations | |
| 483 | - | - [`_meta/diagrams/infra/pom_monitoring.md`](../../../../_meta/diagrams/infra/pom_monitoring.md) — monitoring topology |
| @@ -1,193 +0,0 @@ | |||
| 1 | - | # Chargeback Protection Fund | |
| 2 | - | ||
| 3 | - | *Internal planning document. Post-beta feature — not yet scheduled.* | |
| 4 | - | ||
| 5 | - | A mutual protection pool where participating creators contribute a small percentage of sales revenue into a shared fund that reimburses chargeback losses. MNW takes a small maintenance cut. No creator bears the full cost of a chargeback alone. | |
| 6 | - | ||
| 7 | - | --- | |
| 8 | - | ||
| 9 | - | ## Why This Matters | |
| 10 | - | ||
| 11 | - | A single chargeback on a $15 sale costs the creator ~$31: | |
| 12 | - | ||
| 13 | - | | Component | Amount | | |
| 14 | - | |-----------|--------| | |
| 15 | - | | Lost transaction amount | $15.00 | | |
| 16 | - | | Stripe dispute fee (non-refundable) | $15.00 | | |
| 17 | - | | Stripe processing fee (non-refundable) | ~$0.74 | | |
| 18 | - | | **Total loss** | **~$30.74** | | |
| 19 | - | ||
| 20 | - | Stripe offers Chargeback Protection at 0.4% of all transactions, but it covers fraud chargebacks only. "Product not as described" and "unrecognized" chargebacks — the types most likely on a content platform — are excluded. A platform-managed pool covers all types. | |
| 21 | - | ||
| 22 | - | No platform currently offers a mutual pool among creators. Every existing model either absorbs costs as a service (Shopify, PayPal), charges a flat fee for fraud-only coverage (Stripe), or passes costs through to sellers (Etsy, Gumroad, Patreon). A cooperative model where creators pool risk is genuinely differentiated. | |
| 23 | - | ||
| 24 | - | --- | |
| 25 | - | ||
| 26 | - | ## How It Works | |
| 27 | - | ||
| 28 | - | 1. Participating creators opt in | |
| 29 | - | 2. A percentage of each fan transaction is withheld into the pool | |
| 30 | - | 3. When a chargeback hits, the pool reimburses the creator (transaction amount + dispute fee + processing fee) | |
| 31 | - | 4. MNW takes a small maintenance percentage of pool contributions | |
| 32 | - | 5. Per-creator caps prevent a single bad actor from draining the fund | |
| 33 | - | 6. Experience rating adjusts contributions over time based on chargeback history | |
| 34 | - | ||
| 35 | - | --- | |
| 36 | - | ||
| 37 | - | ## Economics | |
| 38 | - | ||
| 39 | - | ### Assumptions | |
| 40 | - | ||
| 41 | - | - Average fan transaction: $15 | |
| 42 | - | - Chargeback rate for curated digital platform: 0.15% (digital-goods sector average is ~1.85% per Stripe's 2025 industry data; a curated platform with no shipping disputes should sit well below that — see [Stripe: average chargeback rate](https://stripe.com/resources/more/what-is-an-average-chargeback-rate-a-guide-for-ecommerce-businesses)) | |
| 43 | - | - Cost per chargeback: $30.74 | |
| 44 | - | ||
| 45 | - | Industry context: Visa's VAMP (Visa Acquirer Monitoring Program) sets the Excessive Merchant threshold at 1.5% (150 bps) of count-based fraud + disputes over settled transactions, effective April 1, 2026 in US/EU/Canada/AP regions, with a minimum count floor of 1,500 events to focus on significant issues (Visa Acquirer Monitoring Program Fact Sheet 2025: https://corporate.visa.com/content/dam/VCOM/corporate/visa-perspectives/security-and-trust/documents/visa-acquirer-monitoring-program-fact-sheet-2025.pdf; Visa Acceptance Risk Standards: https://usa.visa.com/dam/VCOM/download/merchants/visa-acceptance-risk-standards.pdf). Mastercard's Excessive Chargeback Program (ECP) is documented in the Mastercard Chargeback Guide (27 January 2026: https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/chargeback-guide.pdf) and Security Rules and Procedures Merchant Edition (3 February 2026: https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/SPME-Manual.pdf). Safe operating range is below 0.5%. A curated platform with digital delivery and no shipping disputes should be well below that. | |
| 46 | - | ||
| 47 | - | ### Break-Even Contribution Rate | |
| 48 | - | ||
| 49 | - | ``` | |
| 50 | - | Break-even = (chargeback_rate x cost_per_chargeback) / avg_transaction | |
| 51 | - | = (0.0015 x $30.74) / $15 | |
| 52 | - | = 0.307% | |
| 53 | - | ``` | |
| 54 | - | ||
| 55 | - | With safety margins: | |
| 56 | - | ||
| 57 | - | | Safety Margin | Contribution Rate | | |
| 58 | - | |---------------|-------------------| | |
| 59 | - | | 2x | 0.6% | | |
| 60 | - | | 2.5x | 0.75% | | |
| 61 | - | | 3x | 0.9% | | |
| 62 | - | ||
| 63 | - | <!-- TODO: derive the operative multiplier from Poisson upper-bound at 95th pctile at participant count N (see assumptions.md A21). The 2.5x previously labeled "recommended" was unjustified. --> | |
| 64 | - | ||
| 65 | - | ||
| 66 | - | ### What Creators Pay at 0.75% | |
| 67 | - | ||
| 68 | - | | Monthly Sales | Pool Contribution | Annual Cost | | |
| 69 | - | |---------------|-------------------|-------------| | |
| 70 | - | | $100 | $0.75 | $9 | | |
| 71 | - | | $500 | $3.75 | $45 | | |
| 72 | - | | $2,000 | $15.00 | $180 | | |
| 73 | - | | $10,000 | $75.00 | $900 | | |
| 74 | - | ||
| 75 | - | One prevented chargeback per year pays for itself for any creator doing $500+/month in sales. | |
| 76 | - | ||
| 77 | - | ### Pool Revenue by Scale | |
| 78 | - | ||
| 79 | - | Assumes average creator does $500/month in fan sales. | |
| 80 | - | ||
| 81 | - | | Creators | Monthly GMV | Chargebacks/mo (expected) | Monthly Loss | Pool Income (0.75%) | Surplus | MNW 5% Cut | | |
| 82 | - | |----------|-------------|---------------------------|--------------|---------------------|---------|------------| | |
| 83 | - | | 30 | $15,000 | 1.5 | $46 | $112 | +$66 | $5.63 | | |
| 84 | - | | 100 | $50,000 | 5 | $154 | $375 | +$221 | $18.75 | | |
| 85 | - | | 300 | $150,000 | 15 | $461 | $1,125 | +$664 | $56.25 | | |
| 86 | - | | 1,000 | $500,000 | 50 | $1,537 | $3,750 | +$2,213 | $187.50 | | |
| 87 | - | ||
| 88 | - | MNW's cut is intentionally negligible. This is a trust and differentiation play, not a revenue stream. | |
| 89 | - | ||
| 90 | - | ### Variance Risk | |
| 91 | - | ||
| 92 | - | At small scale, chargebacks follow a Poisson distribution. With 30 creators and 1,000 transactions/month (expected: 1.5 chargebacks/month): | |
| 93 | - | ||
| 94 | - | | Chargebacks in a month | Probability | Pool solvent from contributions alone? | | |
| 95 | - | |------------------------|-------------|----------------------------------------| | |
| 96 | - | | 0 | 22.3% | Yes (surplus) | | |
| 97 | - | | 1 | 33.5% | Yes | | |
| 98 | - | | 2 | 25.1% | Yes | | |
| 99 | - | | 3 | 12.6% | Yes (barely) | | |
| 100 | - | | 4 | 4.7% | Draws on reserves | | |
| 101 | - | | 5+ | 1.4% (sum tail at λ=1.5) | Needs reserves | | |
| 102 | - | ||
| 103 | - | At 0.75% income ($112/mo) and ~$31/chargeback, current contributions cover 3 chargebacks/month. A 4th draws from reserves. This is manageable with a buildup period. | |
| 104 | - | ||
| 105 | - | --- | |
| 106 | - | ||
| 107 | - | ## Operating Rules | |
| 108 | - | ||
| 109 | - | ### Launch Prerequisites | |
| 110 | - | ||
| 111 | - | - Reserve target: 6 months of expected claims before surplus distribution | |
| 112 | - | - IBNR buffer: hold 120 days of reserves at all times (Visa: cardholders have up to 120 days from the transaction or expected delivery date to file most disputes — see Visa Core Rules and Visa Product and Service Rules, 18 April 2026, https://usa.visa.com/dam/VCOM/download/about-visa/visa-rules-public.pdf; Mastercard Chargeback Guide 27 January 2026, https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/chargeback-guide.pdf) | |
| 113 | - | - Minimum participating-creator count and buildup period: TBD, derive from variance ratio threshold and time-to-IBNR-buffer at expected GMV (see assumptions.md A22, A23). | |
| 114 | - | ||
| 115 | - | ### Per-Creator Caps | |
| 116 | - | ||
| 117 | - | | Creator Monthly Sales | Max Covered Chargebacks/Month | | |
| 118 | - | |-----------------------|-------------------------------| | |
| 119 | - | | < $500 | 2 | | |
| 120 | - | | $500-$2,000 | 3 | | |
| 121 | - | | $2,000-$10,000 | 5 | | |
| 122 | - | | $10,000+ | 8 | | |
| 123 | - | ||
| 124 | - | A creator exceeding their cap is likely being targeted. At that point the right response is investigation, not more payouts. | |
| 125 | - | ||
| 126 | - | ### Experience Rating (After 6 Months of Data) | |
| 127 | - | ||
| 128 | - | | Chargeback History | Rate Adjustment | | |
| 129 | - | |---------------------------|-----------------| | |
| 130 | - | | Zero chargebacks | 0.5x (pay 0.375%) | | |
| 131 | - | | At or below pool average | 1.0x (pay 0.75%) | | |
| 132 | - | | Above pool average | 1.5x (pay 1.125%) | | |
| 133 | - | | 2x+ pool average | Removed from pool | | |
| 134 | - | ||
| 135 | - | ### MNW Maintenance Fee | |
| 136 | - | ||
| 137 | - | 5% of pool contributions (not of GMV). Covers: | |
| 138 | - | ||
| 139 | - | - Webhook processing and dispute tracking infrastructure | |
| 140 | - | - Pool accounting and reporting | |
| 141 | - | - Dashboard development and maintenance | |
| 142 | - | ||
| 143 | - | --- | |
| 144 | - | ||
| 145 | - | ## Legal Structure | |
| 146 | - | ||
| 147 | - | **Structure as a platform service, not insurance.** A mutual insurance pool would require licensing in Colorado. Under the Colorado Captive Insurance Companies Act (C.R.S. Title 10, Article 6), no captive may operate unless it maintains total capital and surplus of not less than **$500,000** (C.R.S. § 10-6-116; https://law.justia.com/codes/colorado/title-10/captive-insurance-companies/article-6/section-10-6-116/) — the previous "$100K" figure in this doc was wrong. Plus an actuarial study and ongoing compliance. **Needs lawyer / actuary review of CRS 10-6 if a captive structure is ever revisited.** Instead: | |
| 148 | - | ||
| 149 | - | - Call it "Creator Protection Reserve" — a platform service per the ToS | |
| 150 | - | - Contributions are withheld from payouts, not billed separately | |
| 151 | - | - Payouts from the reserve are at the platform's discretion (not a guaranteed indemnity) | |
| 152 | - | - The fund is MNW's money (not a separate legal entity) | |
| 153 | - | ||
| 154 | - | This is how major platforms structure their seller protection programs — as platform services at the platform's discretion, not insurance contracts. See [PayPal Seller Protection](https://www.paypal.com/us/webapps/mpp/security/seller-protection), [Etsy Purchase Protection for Sellers](https://www.etsy.com/legal/policy/purchase-protection-program-for-sellers/34509585385), and [Shopify Payments Terms](https://www.shopify.com/legal/terms-payments/us). No special licensing required. | |
| 155 | - | ||
| 156 | - | Key legal distinction: MNW is managing its own funds and choosing to absorb certain costs as a business decision, not promising to indemnify third parties against risk. | |
| 157 | - | ||
| 158 | - | --- | |
| 159 | - | ||
| 160 | - | ## Implementation Sketch | |
| 161 | - | ||
| 162 | - | ### New Infrastructure | |
| 163 | - | ||
| 164 | - | 1. **Webhook handler** for `charge.dispute.created` and `charge.dispute.closed` on connected accounts (none exists today) | |
| 165 | - | 2. **Pool ledger table** — contributions, claims, running balance per creator | |
| 166 | - | 3. **Payout mechanism** — credit against future subscription fees or direct transfer | |
| 167 | - | 4. **Opt-in flag** on creator accounts | |
| 168 | - | 5. **Dashboard** — pool health, personal contribution/claims history, experience rating | |
| 169 | - | ||
| 170 | - | ### Data Model (Rough) | |
| 171 | - | ||
| 172 | - | - `chargeback_pool_members` — creator_id, opted_in_at, experience_multiplier | |
| 173 | - | - `chargeback_pool_contributions` — creator_id, transaction_id, amount_cents, created_at | |
| 174 | - | - `chargeback_pool_claims` — creator_id, dispute_id, amount_cents, status, created_at | |
| 175 | - | - `chargeback_pool_balance` — running total, reserve amount | |
| 176 | - | ||
| 177 | - | ### Webhook Flow | |
| 178 | - | ||
| 179 | - | 1. Receive `charge.dispute.created` from connected account | |
| 180 | - | 2. Match to creator, check pool membership | |
| 181 | - | 3. If member and under cap: create claim, mark pending | |
| 182 | - | 4. On `charge.dispute.closed` (lost): pay out from pool | |
| 183 | - | 5. On `charge.dispute.closed` (won): cancel claim, no payout needed | |
| 184 | - | ||
| 185 | - | --- | |
| 186 | - | ||
| 187 | - | ## Open Questions | |
| 188 | - | ||
| 189 | - | - Should the contribution be withheld from payouts or billed as a separate line item? | |
| 190 | - | - Should the pool cover only fan-to-creator transactions, or also Fan+ subscription chargebacks? | |
| 191 | - | - What happens to a creator's contributions if they leave the pool? Refundable? Forfeited? | |
| 192 | - | - Should there be a minimum sales volume to join (to avoid adverse selection from very low-volume creators)? | |
| 193 | - | - How transparent should pool financials be? Full transparency to all members, or just individual dashboards? |
| @@ -1,98 +0,0 @@ | |||
| 1 | - | # Regulatory Compliance | |
| 2 | - | ||
| 3 | - | An overview of what we comply with and how. | |
| 4 | - | ||
| 5 | - | ## Current Compliance | |
| 6 | - | ||
| 7 | - | ### Payment Card Industry (PCI) | |
| 8 | - | ||
| 9 | - | We don't handle card data directly. Stripe handles all card processing, and they maintain PCI DSS compliance. Card numbers never touch our servers. | |
| 10 | - | ||
| 11 | - | This is by design. Handling card data requires significant security infrastructure and ongoing audits. Using Stripe means we get compliant payment processing without that overhead. | |
| 12 | - | ||
| 13 | - | ### Data Protection | |
| 14 | - | ||
| 15 | - | **GDPR (EU) and CCPA (California):** Each enumerated right maps to a concrete code path that fulfills it, plus a verification method. The table below is the canonical mapping; user-facing summaries in [GDPR Compliance](../legal/gdpr.md) and [CCPA Compliance](../legal/ccpa.md) must stay consistent with this table. | |
| 16 | - | ||
| 17 | - | | Right | Code path | Verification method | | |
| 18 | - | |---|---|---| | |
| 19 | - | | Right of access (GDPR Art. 15) / Right to know (CCPA §1798.110) | `src/routes/api/exports/mod.rs` (`export_projects`, `export_sales`, `export_splits`, `export_purchases`, `export_followers`, `export_subscriptions`, `export_contacts`); `src/routes/api/exports/content.rs::export_content` | Manual export test quarterly; verify each endpoint returns subject's data in machine-readable form | | |
| 20 | - | | Right to rectification (GDPR Art. 16) | `src/routes/api/users/profile.rs::update_profile` (also `update_password`); dashboard project/item edit forms under `src/routes/pages/dashboard/` | Manual test quarterly: edit profile fields, confirm persistence and downstream visibility | | |
| 21 | - | | Right to erasure (GDPR Art. 17) / Right to delete (CCPA §1798.105) | `src/routes/api/users/profile.rs::delete_account` (delegates to `db::users::delete_user` or `db::users::schedule_content_removal` for creators with completed sales — 90-day buyer grace window); email-confirmed flow via `request_account_deletion` (same file) and `src/routes/pages/email_actions/account.rs` | Manual test quarterly: delete a test account with and without sales; confirm row removal or scheduled removal; confirm 90-day cleanup via `src/scheduler/cleanup.rs` | | |
| 22 | - | | Right to restriction of processing (GDPR Art. 18) | `src/routes/api/users/profile.rs::deactivate_account` / `reactivate_account` (limbo state); `pause_creator` for tier-level pause | Manual test quarterly: deactivate account, confirm content hidden and processing paused; reactivate, confirm restoration | | |
| 23 | - | | Right to data portability (GDPR Art. 20) | Same export endpoints as Art. 15 — outputs are JSON (metadata) and CSV (transactions); original files in their served format. See `src/routes/api/exports/mod.rs` and `src/routes/api/exports/content.rs` | Verify exported JSON/CSV is structured and machine-readable; quarterly sample import into a spreadsheet to confirm | | |
| 24 | - | | Right to object / opt-out of marketing (GDPR Art. 21; CCPA opt-out of marketing communications) | `src/db/mailing_lists.rs::unsubscribe` / `unsubscribe_from_project`; `src/routes/api/users/notifications.rs::update_notification_preferences`; per-email unsubscribe links generated by `email::generate_unsubscribe_url` | Manual test quarterly: unsubscribe via email link, toggle notification preferences in dashboard, confirm no further emails of that category | | |
| 25 | - | | Right of non-discrimination (CCPA §1798.125) | Enforced structurally — no code path conditions service on consent to data sale; we do not sell personal information | Code review: grep for "sale" / ad-network / data-broker integrations should return zero results in `src/` | | |
| 26 | - | | Right to opt out of sale (CCPA §1798.120) | Not applicable — no data sale occurs (TODO: implement only if data-sale feature is ever introduced; current answer is structural N/A) | Code review confirms no ad-network or data-broker integrations in `src/` | | |
| 27 | - | | Clear consent for data collection (GDPR Art. 6, 7) | Signup forms under `src/routes/auth.rs` and templates; checkout consent for fan email sharing in `src/routes/stripe/checkout/` (per-transaction opt-in) | Manual review of signup and checkout flows quarterly to confirm consent is explicit and granular | | |
| 28 | - | | Privacy by design (GDPR Art. 25) | Structural: no behavioral tracking (no analytics integrations in `src/`); minimal data collection enforced at schema level (`migrations/`); no cross-user data joins in public read paths | Code review and `migrations/` audit annually | | |
| 29 | - | ||
| 30 | - | User-facing summaries: see [GDPR Compliance](../legal/gdpr.md) and [CCPA Compliance](../legal/ccpa.md). Any change to the code paths above must be reflected in those docs and in this table. | |
| 31 | - | ||
| 32 | - | ### Content and Copyright | |
| 33 | - | ||
| 34 | - | **DMCA:** We follow the Digital Millennium Copyright Act safe harbor provisions (17 U.S.C. § 512): | |
| 35 | - | ||
| 36 | - | - Designated agent for takedown notices (TODO: USCO DMCA agent registration not yet on file; register at https://www.copyright.gov/dmca-directory/) | |
| 37 | - | - Prompt response to valid takedowns | |
| 38 | - | - Counter-notification process | |
| 39 | - | - Repeat infringer policy | |
| 40 | - | ||
| 41 | - | See [Copyright & DMCA](../legal/copyright.md) for our full policy. | |
| 42 | - | ||
| 43 | - | ## What We're Working Toward | |
| 44 | - | ||
| 45 | - | ### Money Transmitter Licenses | |
| 46 | - | ||
| 47 | - | Currently, we don't need money transmitter licenses because: | |
| 48 | - | ||
| 49 | - | - Stripe handles all payment processing (Stripe Connect Standard; see https://docs.stripe.com/connect/account-capabilities and https://stripe.com/legal/connect-account) | |
| 50 | - | - Funds flow directly to creators, not through us | |
| 51 | - | - We don't hold or transmit customer funds | |
| 52 | - | ||
| 53 | - | This position is grounded in the Colorado Money Transmitters Act (C.R.S. Title 11, Article 110; see https://colorado.public.law/statutes/crs_title_11_article_110), which defines money transmission as receiving money for transmission. Because MNW never receives fan funds (fans pay creators' connected Stripe accounts directly), we do not perform money transmission as defined in the statute. **Needs lawyer review of CRS 11-110 and Stripe Connect Standard MOR documentation before launch.** | |
| 54 | - | ||
| 55 | - | If we expand to handle payments directly (see [Payment Independence](./payment-independence.md)), we'll need to obtain appropriate licenses. This is a future consideration, not a current requirement. | |
| 56 | - | ||
| 57 | - | See [Money Transmitter Licenses](./mtl.md) for details. | |
| 58 | - | ||
| 59 | - | ### International Expansion | |
| 60 | - | ||
| 61 | - | As we grow into new markets, we'll need to comply with local regulations: | |
| 62 | - | ||
| 63 | - | - Payment regulations vary by country | |
| 64 | - | - Data residency requirements in some jurisdictions | |
| 65 | - | - Tax reporting obligations | |
| 66 | - | ||
| 67 | - | We'll expand thoughtfully, ensuring compliance before entering new markets. | |
| 68 | - | ||
| 69 | - | ## Our Approach | |
| 70 | - | ||
| 71 | - | Compliance sometimes means: | |
| 72 | - | ||
| 73 | - | - Features take longer to build | |
| 74 | - | - Some markets aren't supported yet | |
| 75 | - | - We can't offer every payment option | |
| 76 | - | ||
| 77 | - | But it also means we're not one regulatory action away from shutting down. | |
| 78 | - | ||
| 79 | - | ## Questions | |
| 80 | - | ||
| 81 | - | **"Are you licensed to process payments?"** | |
| 82 | - | ||
| 83 | - | We don't process payments—Stripe does. Stripe is licensed and regulated. We use their infrastructure. | |
| 84 | - | ||
| 85 | - | **"What happens if regulations change?"** | |
| 86 | - | ||
| 87 | - | We adapt. If new requirements apply to us, we'll comply. The $50K legal reserve in `reserve_policy.md` ($S_\text{legal}$ component of $R_\text{cap}$) is specifically sized to cover defense costs and settlements for a single contested incident, including any unexpected compliance work that surfaces. | |
| 88 | - | ||
| 89 | - | **"Can I see your compliance certifications?"** | |
| 90 | - | ||
| 91 | - | We don't hold certifications directly (PCI, SOC 2, etc.) because we don't handle the data those certifications cover. Our providers (Stripe, cloud infrastructure) hold relevant certifications. | |
| 92 | - | ||
| 93 | - | ## See Also | |
| 94 | - | ||
| 95 | - | - [Money Transmitter Licenses](./mtl.md) — why MTLs matter for payment processing | |
| 96 | - | - [Payment Independence](./payment-independence.md) — our payment roadmap | |
| 97 | - | - [Privacy Policy](../../public/legal/privacy-policy.md) — how we handle your data | |
| 98 | - | - [Terms of Service](../../public/legal/terms-of-service.md) — our legal obligations |
| @@ -1,215 +0,0 @@ | |||
| 1 | - | # Economics — Principles and Framework | |
| 2 | - | ||
| 3 | - | **As of: 2026-05-16.** | |
| 4 | - | ||
| 5 | - | **Status: canonical for principles and framework. Not canonical for numbers.** | |
| 6 | - | ||
| 7 | - | This is the internal principles doc. It explains *how* MNW thinks about cost, price, surplus, and reserves — the framework that ties the numeric docs together. It does **not** restate per-tier costs, per-creator margins, $R_\text{cap}$ values, or burn rates. Those live in the canonical numeric docs (see §References). Where this doc would otherwise quote a number, it cites instead. | |
| 8 | - | ||
| 9 | - | For the creator-facing version, see `site-docs/public/about/economics.md`. That page contains only what creators need to know. | |
| 10 | - | ||
| 11 | - | --- | |
| 12 | - | ||
| 13 | - | ## 1. Mandate | |
| 14 | - | ||
| 15 | - | MNW operates under two stated commitments that are in direct tension: | |
| 16 | - | ||
| 17 | - | 1. **Prices should not rise.** Creators get stability. | |
| 18 | - | 2. **Prices should stay close to cost-to-deliver.** Creators don't fund extraction. | |
| 19 | - | ||
| 20 | - | The framework below is the mechanism that lets both hold simultaneously. The short version: prices are set close to cost; reserves absorb shocks so prices don't have to move; surplus above the reserve cap returns to creators as earn-back credit. | |
| 21 | - | ||
| 22 | - | This is **cost-plus with bounded reserves**, not value extraction. The platform is not optimizing for maximum margin; it is optimizing for stable, defensible pricing that tracks underlying cost over time. | |
| 23 | - | ||
| 24 | - | --- | |
| 25 | - | ||
| 26 | - | ## 2. The four components | |
| 27 | - | ||
| 28 | - | Every dollar a creator pays goes into one of four buckets. The bucket sizes — and the rules for moving between them — are the entire framework. | |
| 29 | - | ||
| 30 | - | ### 2.1 Cost-to-deliver | |
| 31 | - | ||
| 32 | - | The marginal cost of serving that creator: storage, egress, payment processing, plus the amortized share of fixed platform cost. Per-tier numbers and methodology live in `tech_costs.md`. The framework treats this as the *floor* of any tier price. | |
| 33 | - | ||
| 34 | - | The "fixed platform cost" component is itself amortized across active creators — as creator count grows, the per-creator share of $F$ (per `expenses.md`) shrinks. See `assumptions.md` A26 (platform-overhead time per active creator). | |
| 35 | - | ||
| 36 | - | What is **not** included in cost-to-deliver: | |
| 37 | - | - T1 (bug-driven) ticket time — that's a quality failure that should drive bug fixes, not pricing. | |
| 38 | - | - T2 (UX-error-driven) ticket time — that's a design failure that should drive UX work, not pricing. | |
| 39 | - | - T3 (abuse) ticket time — bounded by structural defenses, not by per-creator pricing. | |
| 40 | - | ||
| 41 | - | See `assumptions.md` A27. The point: per-creator ticket time is not a COGS line. | |
| 42 | - | ||
| 43 | - | ### 2.2 Reserve maintenance ($R_\text{cap}$) | |
| 44 | - | ||
| 45 | - | A bounded, one-time savings target that exists to absorb shocks (vendor pricing changes, legal incidents, viral bandwidth spikes) without forcing a price increase. Once filled, the *margin that funded it* can shrink toward zero — reserves persist, the contribution rate does not. | |
| 46 | - | ||
| 47 | - | $R_\text{cap}$ formula, current value, and the surplus-disposition rule live in `reserve_policy.md`. The current value is computed from $F$ in `expenses.md`. | |
| 48 | - | ||
| 49 | - | The key property: $R_\text{cap}$ is *bounded*. It is not a perpetual margin requirement. Once full, surplus flows past it. | |
| 50 | - | ||
| 51 | - | ### 2.3 Opportunistic fund ($R_\text{opp}$) | |
| 52 | - | ||
| 53 | - | A separate, bounded discretionary bucket for mission-aligned spending — event sponsorships, charitable contributions to FOSS projects, opportunistic marketing, strategic gifts. Capped at a low fixed dollar amount with hard per-incident and annual spend ceilings. | |
| 54 | - | ||
| 55 | - | $R_\text{opp}$ is **bounded**, not extraction-margin. See `reserve_policy.md` §3 for the cap value, spend rules, and annual public disclosure mechanism. | |
| 56 | - | ||
| 57 | - | ### 2.4 Return to creators (earn-back credit) | |
| 58 | - | ||
| 59 | - | The continuous-return mechanism. Once $R_\text{cap}$ and $R_\text{opp}$ are filled, surplus flows primarily to earn-back credit — the documented commitment that creators who put in more than they got out receive credit toward future months. Committed to launch no later than 2027-01-01. | |
| 60 | - | ||
| 61 | - | Earn-back is what lets prices be set conservatively at cost-plus-buffer without that buffer functioning as extraction. If costs come in lower than the buffer assumed, surplus returns to creators rather than accumulating indefinitely. See `reserve_policy.md` §4 for the surplus split. | |
| 62 | - | ||
| 63 | - | --- | |
| 64 | - | ||
| 65 | - | ## 3. Why not "we have healthy margins" | |
| 66 | - | ||
| 67 | - | Earlier framings of this doc described MNW as having "healthy margins" with the implicit assumption that those margins were the goal. That framing is wrong for the model and is removed. | |
| 68 | - | ||
| 69 | - | The goal is not high margin. The goal is **price stability close to cost over time**. The current per-tier price minus current per-tier cost looks like a healthy margin only because: | |
| 70 | - | ||
| 71 | - | - Fixed costs are amortized over a small creator base, and the per-creator amortization will fall as N grows. | |
| 72 | - | - Reserves are unfilled, so the per-creator surplus is currently flowing into building $R_\text{cap}$, not into ongoing extraction. | |
| 73 | - | - Earn-back is committed but not yet implemented, so retained surplus has not yet rotated back to creators. | |
| 74 | - | ||
| 75 | - | In steady state — reserves full, earn-back active — the effective economic price to creators tracks cost-to-deliver. The nominal sticker price stays put; the economic price drops via earn-back credit. | |
| 76 | - | ||
| 77 | - | This is the framework. The numbers that go in it live in the docs cited below. | |
| 78 | - | ||
| 79 | - | --- | |
| 80 | - | ||
| 81 | - | ## 4. Pricing tiers | |
| 82 | - | ||
| 83 | - | Tier names and prices are set per `pricing.md`. Founding-cohort rate and standard rate run in parallel; the standard rate is provisional until cohort data exists. | |
| 84 | - | ||
| 85 | - | This doc does **not** restate tier prices. It does observe two structural points: | |
| 86 | - | ||
| 87 | - | - Tiers reflect actual cost differences (video egress > audio egress > text), not feature gating. There are no "pro" tiers that lock features behind a higher price. | |
| 88 | - | - The platform does not take a percentage of creator revenue. The only Stripe cost MNW pays is processing on the creator's tier subscription itself; fan-to-creator transactions flow through Stripe Connect Standard ($0 platform fee). See `tech_costs.md`. | |
| 89 | - | ||
| 90 | - | The decision protocol for any future price change — including the analysis inputs (cost-to-deliver, reserve health, cohort signup velocity, runway model) — is in `pricing.md` §4 and `sops/pricing-change-decision.md`. No public formula, no public trigger thresholds. | |
| 91 | - | ||
| 92 | - | --- | |
| 93 | - | ||
| 94 | - | ## 5. Revenue sources | |
| 95 | - | ||
| 96 | - | Creator subscriptions are the primary revenue source. Three secondary streams exist or are planned: | |
| 97 | - | ||
| 98 | - | 1. **App sync subscriptions** (GO, BB, AF). Independent users, separate acquisition funnels. Per-app pricing and margins in `app_sync_pricing.md`. | |
| 99 | - | 2. **Fan+ consumer subscription**. Per-subscriber economics in `fan-plus.md`; net flow in `financial_dashboard.md`. | |
| 100 | - | 3. **SyncKit SDK** (B2B, not yet productized). Pricing model in `synckit_pricing.md`. | |
| 101 | - | ||
| 102 | - | The secondary streams shorten the creator-count runway needed to break even on fixed costs. They do not change the framework above — surplus from any source flows through the same disposition rule in `reserve_policy.md` §4. | |
| 103 | - | ||
| 104 | - | ### App sync as a fixed-cost offset | |
| 105 | - | ||
| 106 | - | At plausible adoption levels, app sync subscriptions are expected to offset a meaningful share of $F$. The specific adoption scenarios and the resulting net effect on break-even are in `financial_dashboard.md` (App Sync section + Combined Break-Even table). This doc does not restate those numbers. | |
| 107 | - | ||
| 108 | - | What this doc *does* note: earlier prose claimed app sync at "moderate adoption" would cover "the full ~$600/mo infrastructure cost." That claim conflated two different numbers (moderate-adoption revenue, per `financial_dashboard.md`, is in the same general range as $F = \$580/mo$ per `expenses.md`, but the relationship is not "clears" — it's "approximately offsets, with variance"). The accurate statement is: at moderate adoption, app sync revenue is *of the same order of magnitude* as ops-only fixed cost. It does not cover ops + salary. See `financial_dashboard.md` Combined Break-Even table for the actual creator-count math. | |
| 109 | - | ||
| 110 | - | --- | |
| 111 | - | ||
| 112 | - | ## 6. Cost structure (pointer, not restatement) | |
| 113 | - | ||
| 114 | - | | Question | Canonical doc | | |
| 115 | - | |---|---| | |
| 116 | - | | What is current monthly fixed burn ($F$)? | `expenses.md` | | |
| 117 | - | | What are per-tier variable costs? | `tech_costs.md` | | |
| 118 | - | | What are per-tier margins and break-even creator counts? | `financial_dashboard.md` | | |
| 119 | - | | What is $R_\text{cap}$ and its current balance? | `reserve_policy.md` | | |
| 120 | - | | What are the measurement proxies for every assumption? | `assumptions.md` | | |
| 121 | - | | What is the Stripe fee formula? | `stripe_fees.md` | | |
| 122 | - | | What are the Hetzner SKU prices? | `hetzner_prices.md` | | |
| 123 | - | | What is the assumed tier mix and how is it measured? | `tier_mix.md` | | |
| 124 | - | ||
| 125 | - | Citations rather than restatements: ($F = \$580/mo$ per `expenses.md`); per-tier costs per `tech_costs.md`; break-even creator counts per `financial_dashboard.md`. | |
| 126 | - | ||
| 127 | - | --- | |
| 128 | - | ||
| 129 | - | ## 7. What "profitability" means here | |
| 130 | - | ||
| 131 | - | The framework's success conditions, in priority order: | |
| 132 | - | ||
| 133 | - | 1. **Cover cost-to-deliver.** The platform stays online and creators get the service they paid for. This is the floor. | |
| 134 | - | 2. **Build $R_\text{cap}$.** Bank a one-time savings buffer so input shocks don't translate into price increases. | |
| 135 | - | 3. **Maintain $R_\text{opp}$.** Keep the bounded discretionary fund topped up for mission-aligned activity. | |
| 136 | - | 4. **Return surplus.** Above the cap, surplus flows to earn-back credit. | |
| 137 | - | 5. **Evaluate price decreases.** When trailing-12-month surplus exceeds what's needed for (1)–(4), consider whether the standard rate should drop. Price decreases apply retroactively to active subs (cost-favorable changes propagate). | |
| 138 | - | ||
| 139 | - | Founder runway (4.4 years per `financial_dashboard.md`) is a separate concern from (1)–(5) — it is what makes the framework safe to execute, not part of the framework itself. The personal-to-company transition is documented in `reserve_policy.md` §6. | |
| 140 | - | ||
| 141 | - | ### What this framework does not do | |
| 142 | - | ||
| 143 | - | - **Raise prices to accelerate profitability.** Not a goal. | |
| 144 | - | - **Take investment.** Investor obligations would impose growth targets that conflict with the framework. | |
| 145 | - | - **Add premium feature tiers.** Tiers track cost difference, not artificial segmentation. | |
| 146 | - | - **Take a percentage of creator revenue.** Structurally excluded. | |
| 147 | - | ||
| 148 | - | --- | |
| 149 | - | ||
| 150 | - | ## 8. Risk factors | |
| 151 | - | ||
| 152 | - | ### Cost-side risks | |
| 153 | - | ||
| 154 | - | - CDN egress spikes from viral content. Mitigated by $S_\text{shock}$ in $R_\text{cap}$ and by Cloudflare cache; see `reserve_policy.md` §2. | |
| 155 | - | - Storage growth faster than the tier-mix assumptions. Mitigated by monitoring `assumptions.md` A1–A3 monthly. | |
| 156 | - | - Vendor pricing change (Hetzner, Stripe, Postmark, etc.). Mitigated by reserve drawdown rather than price pass-through; see `reserve_policy.md` §5. | |
| 157 | - | - Compliance/regulatory cost increase. Mitigated by $S_\text{legal}$ in $R_\text{cap}$. | |
| 158 | - | ||
| 159 | - | ### Revenue-side risks | |
| 160 | - | ||
| 161 | - | - Churn higher than expected. Mitigated by month-to-month subscriptions (early signal) and conservative cost structure. | |
| 162 | - | - Tier-mix skews cheaper than assumed `tier_mix.md`. Falls through to slower break-even, not platform failure. | |
| 163 | - | - Slow signup velocity at standard rate after founding cohort closes. This is the elasticity signal in `pricing.md` §5 — informs but does not auto-trigger any pricing decision. | |
| 164 | - | ||
| 165 | - | ### Operational risks | |
| 166 | - | ||
| 167 | - | - Bus factor 1. Mitigated by automated infrastructure (runs unattended), source-available license (PolyForm Noncommercial 1.0.0), and the shutdown protocol in `guarantees.md`. | |
| 168 | - | ||
| 169 | - | --- | |
| 170 | - | ||
| 171 | - | ## 9. Long-term scenarios | |
| 172 | - | ||
| 173 | - | **Growth.** More creators → lower per-creator share of $F$ → ongoing surplus → reserves fill faster → earn-back credit activates sooner → standard-rate review with more data. | |
| 174 | - | ||
| 175 | - | **Plateau.** Stable creator base, stable cost structure, sustainable operation. Reserves fill more slowly but still fill. No dependency on growth. | |
| 176 | - | ||
| 177 | - | **Decline.** See `guarantees.md` shutdown protocol. Reserves are sized to fund 12 months of fixed costs precisely so a wind-down is orderly. | |
| 178 | - | ||
| 179 | - | --- | |
| 180 | - | ||
| 181 | - | ## 10. Price commitment | |
| 182 | - | ||
| 183 | - | Per `guarantees.md` (public) and `pricing.md` §4: | |
| 184 | - | ||
| 185 | - | - Prices will not rise except under conditions enumerated in `guarantees.md`. | |
| 186 | - | - 90 days notice on any change. | |
| 187 | - | - 12-month grandfathering for any creator on a higher rate. Cost-favorable changes apply retroactively. | |
| 188 | - | - Reasoning is published with the change. | |
| 189 | - | ||
| 190 | - | Acceptable reasons for a price increase: major shift in vendor pricing, regulatory cost increase, structural change in payment-processor terms. | |
| 191 | - | ||
| 192 | - | Not acceptable: "we want to grow faster," "we want to hire more," "investors want returns" (no investors), "competitors charge more." | |
| 193 | - | ||
| 194 | - | --- | |
| 195 | - | ||
| 196 | - | ## 11. References | |
| 197 | - | ||
| 198 | - | Numeric canonical docs: | |
| 199 | - | - `expenses.md` — $F$ (current monthly fixed burn), itemized | |
| 200 | - | - `tech_costs.md` — per-tier variable costs and projections | |
| 201 | - | - `financial_dashboard.md` — break-even tables, runway, combined revenue scenarios | |
| 202 | - | - `reserve_policy.md` — $R_\text{cap}$, $R_\text{opp}$, surplus disposition | |
| 203 | - | - `pricing.md` — founding-cohort and standard-rate framework, change protocol | |
| 204 | - | - `assumptions.md` — every numeric assumption with proxy and cadence | |
| 205 | - | - `stripe_fees.md`, `hetzner_prices.md`, `tier_mix.md` — vendor and methodology references | |
| 206 | - | ||
| 207 | - | Related principles docs: | |
| 208 | - | - `guarantees.md` (public) — the commitments the framework backs | |
| 209 | - | - `payment-independence.md` — payment-processing posture | |
| 210 | - | - `app_sync_pricing.md` — app revenue model | |
| 211 | - | - `fan-plus.md` — Fan+ economics | |
| 212 | - | - `synckit_pricing.md` — B2B SDK model | |
| 213 | - | ||
| 214 | - | Public-facing version of this page: | |
| 215 | - | - `site-docs/public/about/economics.md` — short, dollars-only, no formulas |
| @@ -1,71 +0,0 @@ | |||
| 1 | - | # Expense Ledger | |
| 2 | - | ||
| 3 | - | **As of: 2026-05-16.** Update when any line changes. | |
| 4 | - | ||
| 5 | - | Actual business expenses for Make Creative, LLC. The canonical source for `F` (monthly fixed burn) used in `reserve_policy.md` and `pricing.md`. Itemized at the invoice level. | |
| 6 | - | ||
| 7 | - | ## Recurring Monthly | |
| 8 | - | ||
| 9 | - | | Expense | Vendor | Amount | Start Date | Term | Notes | | |
| 10 | - | |---------|--------|--------|------------|------|-------| | |
| 11 | - | | Hetzner (all infra) | Hetzner | $31.00/mo | — | Monthly | CCX13 prod ($14.00), 2× CPX11 CI ($5.96), backups ($2.80), S3 ($5.99), volumes ($0.90), 3× IPv4 ($1.35). Invoice 081000817566 (March 2026). See `hetzner_prices.md` for SKU detail. | | |
| 12 | - | | Coworking (Irvine) | Industrious | $332.00/mo | 2026-05-01 | Month-to-month | Access membership, 24/7, 3 meeting room hrs/mo, mailbox. 3333 Michelson Dr, Suite 300, Irvine CA 92612. | | |
| 13 | - | | Claude Code | Anthropic | $200.00/mo | — | Monthly | Max plan. Primary development tool. | | |
| 14 | - | | Fastmail | Fastmail | ~$5/mo | — | Annual | Business email (support@, legal@, max@). Standard plan, single user with aliases. Verify next invoice. See `vendor_prices.md`. | | |
| 15 | - | | Domain registrations | Cloudflare Registrar | ~$2/mo | — | Annual (amortized) | makenot.work (.work ~$8/yr) + others. TODO: inventory each domain with renewal cost. | | |
| 16 | - | | Cloudflare | Cloudflare | $0/mo | — | — | Free plan. Budget $25/mo for Pro when needed. See `vendor_prices.md`. | | |
| 17 | - | | Postmark | Postmark | ~$0/mo | — | Free trial | Under 100 lifetime sends. Budget $15/mo at Starter once volume grows. | | |
| 18 | - | | Apple Developer Program | Apple | ~$8.25/mo amortized | — | Annual ($99/yr) | Required for app distribution (AF, GO, BB). | | |
| 19 | - | | CO LLC Periodic Report | CO Secretary of State | ~$0.83/mo amortized | — | Annual ($10/yr) | Required to keep LLC in good standing. | | |
| 20 | - | ||
| 21 | - | ### Founder Salary | |
| 22 | - | ||
| 23 | - | | Period | Monthly | Annual | | |
| 24 | - | |--------|---------|--------| | |
| 25 | - | | Months 1-12 | $3,000 | $36,000 | | |
| 26 | - | | Month 13+ | $5,000 | $60,000 | | |
| 27 | - | ||
| 28 | - | Year 2 upgrade contingent on revenue growth. If revenue has not materialized by month 13, additional funding or cost reduction needed. | |
| 29 | - | ||
| 30 | - | **Not business expenses:** Sourcehut ($10/mo, personal). | |
| 31 | - | ||
| 32 | - | ### Monthly totals | |
| 33 | - | ||
| 34 | - | Itemized sum: $31 + $332 + $200 + $5 + $2 + $0 + $0 + $8.25 + $0.83 = **$579.08/mo**, rounded to **$580**. | |
| 35 | - | ||
| 36 | - | This is the canonical value of $F$ for `reserve_policy.md` and `pricing.md`. Update both when this changes by >10%. | |
| 37 | - | ||
| 38 | - | | Scenario | Ops Only | + $3K Salary | + $5K Salary | | |
| 39 | - | |----------|---------|-------------|-------------| | |
| 40 | - | | **Current actual** | **~$580** | **~$3,580** | **~$5,580** | | |
| 41 | - | | + Cloudflare Pro | ~$605 | ~$3,605 | ~$5,605 | | |
| 42 | - | | + Postmark Starter ($15) | ~$595 | ~$3,595 | ~$5,595 | | |
| 43 | - | | + Boulder coworking (alt to Irvine) | ~$937 | ~$3,937 | ~$5,937 | | |
| 44 | - | | Full budgeted (all + legal/insurance) | ~$1,120–1,435 | ~$4,120–4,435 | ~$6,120–6,435 | | |
| 45 | - | ||
| 46 | - | ## One-Time / Completed | |
| 47 | - | ||
| 48 | - | | Expense | Amount | Date | Notes | | |
| 49 | - | |---------|--------|------|-------| | |
| 50 | - | | LLC formation (CO) | — | 2026 | Make Creative, LLC | | |
| 51 | - | | Launch expenses (misc) | ~$2,000 | 2026-02 to 2026-04 | Infrastructure, domains, initial setup | | |
| 52 | - | ||
| 53 | - | ## Expense Categories for Tax | |
| 54 | - | ||
| 55 | - | | Category | IRS Deduction | Expenses | | |
| 56 | - | |----------|---------------|----------| | |
| 57 | - | | Salary / guaranteed payments | Schedule C, Line 26 (Wages) or SE income | Founder salary (depends on LLC tax election) | | |
| 58 | - | | Office / coworking | Schedule C, Line 20b (Rent) | Industrious memberships | | |
| 59 | - | | Web hosting / infrastructure | Schedule C, Line 27a (Other expenses) | Hetzner, domains, Cloudflare | | |
| 60 | - | | Software / tools | Schedule C, Line 27a | Claude Code, dev tools | | |
| 61 | - | | Communications / email | Schedule C, Line 27a | Postmark | | |
| 62 | - | | Legal / compliance | Schedule C, Line 17 | LLC filing, legal counsel | | |
| 63 | - | | Travel | Schedule C, Line 24a | Events, conferences | | |
| 64 | - | ||
| 65 | - | ## Notes | |
| 66 | - | ||
| 67 | - | - Industrious is a license agreement, not a lease — classified as rent/office expense for tax purposes. | |
| 68 | - | - Month-to-month terms: 1 calendar month non-renewal notice required. | |
| 69 | - | - Auto-renews unless cancelled. Price adjustments capped at 10% with 80 days notice. | |
| 70 | - | - No security deposit on current agreement. | |
| 71 | - | - Meeting room hours (3/mo included) are useful for creator pitches, investor meetings, and partner calls. |
| @@ -1,186 +0,0 @@ | |||
| 1 | - | # Fan+ Design | |
| 2 | - | ||
| 3 | - | Platform-wide consumer subscription, part of the economic model from launch. | |
| 4 | - | ||
| 5 | - | ## Pricing | |
| 6 | - | ||
| 7 | - | - **$8/month**, month-to-month, cancel anytime | |
| 8 | - | - $5 of the $8 is returned as platform credit (62.5%) | |
| 9 | - | - MNW keeps $2.47/mo net ($8 − $0.53 Stripe − $5 credit; see stripe_fees.md) | |
| 10 | - | - Credit must be spent within the billing month — no rollover, no cash-out | |
| 11 | - | ||
| 12 | - | ## Credit | |
| 13 | - | ||
| 14 | - | ### How it works | |
| 15 | - | ||
| 16 | - | Each billing cycle, the subscriber receives a single-use promo code worth $5 off any purchase on the platform. Delivered via email using existing promo code infrastructure. | |
| 17 | - | ||
| 18 | - | ### Code mechanics | |
| 19 | - | ||
| 20 | - | - Type: `discount`, fixed $5 | |
| 21 | - | - Scope: platform-wide (no item/project restriction) | |
| 22 | - | - Max uses: 1 | |
| 23 | - | - Expires: end of billing month | |
| 24 | - | - Stacks with nothing — one code per checkout | |
| 25 | - | ||
| 26 | - | ### What credit can buy | |
| 27 | - | ||
| 28 | - | - One-time item purchases | |
| 29 | - | - Creator subscription payments (first month or renewal) | |
| 30 | - | - PWYW top-ups (pay more than the minimum) | |
| 31 | - | - Gifted purchases (when gifting ships) | |
| 32 | - | ||
| 33 | - | ### What happens if the item costs less than $5 | |
| 34 | - | ||
| 35 | - | The remainder is lost. No change, no partial codes, no balance tracking. This keeps the system simple — a promo code, not a wallet. | |
| 36 | - | ||
| 37 | - | ### What happens if the subscriber doesn't use it | |
| 38 | - | ||
| 39 | - | It expires. No rollover. This is a feature, not a bug — it creates gentle urgency to spend, which drives revenue to creators every month. | |
| 40 | - | ||
| 41 | - | ## Perks | |
| 42 | - | ||
| 43 | - | ### Forum features (Multithreaded) | |
| 44 | - | ||
| 45 | - | Fan+ unlocks storage-heavy forum capabilities: | |
| 46 | - | ||
| 47 | - | - **Signatures** — text + image, rendered on every post | |
| 48 | - | - **Custom / larger profile images** — beyond the default generated avatar | |
| 49 | - | - **Image and video embeds in posts** — inline media in thread replies | |
| 50 | - | - **Private community access** — Fan+-gated communities (e.g., MNW development community) | |
| 51 | - | ||
| 52 | - | Free accounts can read everything, post text, search, endorse, and track threads. The free experience is fully functional for discussion — Fan+ adds rich media participation. | |
| 53 | - | ||
| 54 | - | **Creator exception:** Creators automatically receive all Fan+ forum perks in their own communities at no additional cost. They already pay $10-60/mo for the platform. The only Fan+-exclusive perk creators do not receive is the + badge — that signals "I'm a fan who pays," not "I'm a creator." | |
| 55 | - | ||
| 56 | - | This gating serves three purposes: | |
| 57 | - | 1. Storage-expensive features (signatures rendered on every post, inline media) are funded by the people using them | |
| 58 | - | 2. Paying users have skin in the game, reducing spam and low-effort posting | |
| 59 | - | 3. Creators can showcase the upgraded experience in their own communities, creating a natural upsell | |
| 60 | - | ||
| 61 | - | ### `+` badge | |
| 62 | - | ||
| 63 | - | A `+` appears after the subscriber's username in every social context: | |
| 64 | - | ||
| 65 | - | - Follower lists ("alice+" follows you) | |
| 66 | - | - Contact sharing (purchase receipts, creator dashboard) | |
| 67 | - | - Broadcast recipient lists | |
| 68 | - | - Forum posts (Multithreaded) | |
| 69 | - | - Future: polls | |
| 70 | - | ||
| 71 | - | Not an emoji. Not a color. A single character that signals participation without being loud. | |
| 72 | - | ||
| 73 | - | ### Platform polls | |
| 74 | - | ||
| 75 | - | Fan+ subscribers can vote on upcoming platform features. Polls are advisory, not binding. "We asked Fan+ members what to build next" is marketing copy, not governance. | |
| 76 | - | ||
| 77 | - | Polls are lightweight — a simple form with 2-4 options, results visible to voters. No elaborate voting infrastructure needed. Can start as a category in the Fan+ forum on Multithreaded. | |
| 78 | - | ||
| 79 | - | ### Development community | |
| 80 | - | ||
| 81 | - | Access to a private space for discussion about MNW's development, roadmap, and direction. | |
| 82 | - | ||
| 83 | - | **Implementation:** Private forum on Multithreaded (forums.makenot.work), Fan+-gated access. On-brand — runs on MNW's own infrastructure, no third-party dependency. MNW OAuth login means subscribers already have accounts. | |
| 84 | - | ||
| 85 | - | The community is valuable because: | |
| 86 | - | - It runs on our own infrastructure (Multithreaded, deployed and audited) | |
| 87 | - | - It's inherently exclusive without hiding features — you're curating a room, not gating functionality | |
| 88 | - | - It makes subscribers feel like stakeholders | |
| 89 | - | - It gets more valuable as the platform grows | |
| 90 | - | - Forum format (immutable posts, verified quoting, endorsements) suits development discussion better than chat | |
| 91 | - | ||
| 92 | - | ## What Fan+ is NOT | |
| 93 | - | ||
| 94 | - | - **Not core feature gating.** Every core platform feature is available to free users. Wishlist, collections, gifting, export, follows, feed, library, forum reading and text posting — all free. Fan+ unlocks rich media participation in forums, not access to the platform itself. | |
| 95 | - | - **Not ad removal.** MNW has no ads. | |
| 96 | - | - **Not priority support.** One person runs the platform. Promising tiers of support is dishonest. | |
| 97 | - | - **Not early access.** Features ship to everyone at the same time. Promising early access creates resentment and is hard to deliver consistently. | |
| 98 | - | ||
| 99 | - | ## Economics | |
| 100 | - | ||
| 101 | - | ### Per-subscriber unit economics | |
| 102 | - | ||
| 103 | - | | Line | Amount | | |
| 104 | - | |------|--------| | |
| 105 | - | | Fan pays | $8.00 | | |
| 106 | - | | Stripe processing | -$0.53 (2.9% + $0.30 per stripe_fees.md) | | |
| 107 | - | | Credit issued | -$5.00 | | |
| 108 | - | | **MNW net per subscriber** | **$2.47** | | |
| 109 | - | ||
| 110 | - | The $5 credit is only a cost when redeemed — if a subscriber forgets to use it, MNW keeps the full $7.47. But the design assumes most subscribers will use it (that's the point). | |
| 111 | - | ||
| 112 | - | ### Revenue at scale | |
| 113 | - | ||
| 114 | - | | Fan+ subscribers | Monthly net to MNW | Annual net | | |
| 115 | - | |------------------|-------------------|------------| | |
| 116 | - | | 100 | $247 | $2,964 | | |
| 117 | - | | 500 | $1,235 | $14,820 | | |
| 118 | - | | 1,000 | $2,470 | $29,640 | | |
| 119 | - | ||
| 120 | - | ### Creator impact | |
| 121 | - | ||
| 122 | - | Every active Fan+ subscriber spends $5/month on the platform. With 500 subscribers, that's $2,500/month flowing to creators as purchases — on top of whatever they'd spend anyway. The credit creates habitual spending. | |
| 123 | - | ||
| 124 | - | ### Interaction with creator earn-back | |
| 125 | - | ||
| 126 | - | Credit-funded purchases count as real sales for creator earn-back calculations. A sale is a sale regardless of funding source. This means Fan+ indirectly subsidizes small creators' subscription costs. | |
| 127 | - | ||
| 128 | - | ## Implementation | |
| 129 | - | ||
| 130 | - | ### Database | |
| 131 | - | ||
| 132 | - | - `fan_plus_subscriptions` table (user_id, stripe_subscription_id, status, current_period_start, current_period_end, created_at) | |
| 133 | - | - Or: reuse existing subscription infrastructure with a platform-level "Fan+" tier | |
| 134 | - | ||
| 135 | - | ### Stripe | |
| 136 | - | ||
| 137 | - | - Single Stripe Product ("Fan+") with one Price ($8/month) | |
| 138 | - | - Webhook handles: subscription created, renewed, cancelled, payment failed | |
| 139 | - | - On renewal: generate promo code, email to subscriber | |
| 140 | - | ||
| 141 | - | ### Promo code generation | |
| 142 | - | ||
| 143 | - | On each successful billing cycle: | |
| 144 | - | 1. Generate a unique promo code (word-based, e.g., "maple-river-stone") | |
| 145 | - | 2. Insert into `promo_codes` table: purpose=discount, discount_type=fixed, discount_value=500, max_uses=1, expires_at=period_end, scoped to user | |
| 146 | - | 3. Email code to subscriber with expiry date | |
| 147 | - | ||
| 148 | - | ### Badge | |
| 149 | - | ||
| 150 | - | - Add `is_fan_plus` boolean (or check active subscription) to user queries in social contexts | |
| 151 | - | - Append `+` to username in template rendering where social context applies | |
| 152 | - | - No separate display_name field — the `+` is presentational, not stored in username | |
| 153 | - | ||
| 154 | - | ### Community | |
| 155 | - | ||
| 156 | - | - Multithreaded: create private Fan+ community, gate access via Fan+ subscription status check | |
| 157 | - | - MNW OAuth login means no separate account needed | |
| 158 | - | ||
| 159 | - | ## Messaging | |
| 160 | - | ||
| 161 | - | ### For the economics/pricing page | |
| 162 | - | ||
| 163 | - | > **Fan+** — $8/month | |
| 164 | - | > | |
| 165 | - | > $5 in monthly credit to spend on any creator's work. A `+` by your name. A seat at the table for platform development. | |
| 166 | - | > | |
| 167 | - | > 62% of your subscription goes directly to creators. The rest keeps the lights on. Cancel anytime. | |
| 168 | - | ||
| 169 | - | ### For the guarantees page | |
| 170 | - | ||
| 171 | - | > Fan+ is optional. Every platform feature works without it. The subscription exists to create a flywheel: your credit funds creators, creators make more work, you find more to spend on. If we ever shut down Fan+, active subscribers get a prorated refund. (SOP: TBD; see sops/fan-plus-shutdown.md when written.) | |
| 172 | - | ||
| 173 | - | ### Strategic rationale for launch timing | |
| 174 | - | ||
| 175 | - | - Establishes consumer revenue as a built-in component, not a later course correction under revenue pressure. | |
| 176 | - | - Puts the $5 credit flow into the marketplace economy from day one, supporting creators while Fan+ subscribers explore content. | |
| 177 | - | ||
| 178 | - | ## Open items | |
| 179 | - | ||
| 180 | - | - [ ] Decide: reuse existing subscription infra or build Fan+-specific tables | |
| 181 | - | - [ ] Implement Fan+ access gating in Multithreaded (private community, subscription check) | |
| 182 | - | - [ ] Implement Fan+ forum feature gates (signatures, custom images, image/video embeds) | |
| 183 | - | - [ ] Implement creator auto-grant of Fan+ forum perks in own communities (no + badge) | |
| 184 | - | - [ ] Write guarantees page copy | |
| 185 | - | - [ ] Write economics page copy | |
| 186 | - | - [ ] Design email template for monthly credit delivery |
| @@ -1,353 +0,0 @@ | |||
| 1 | - | # Financial Dashboard | |
| 2 | - | ||
| 3 | - | Current burn: $3,580/mo (actual ops + $3K salary; per expenses.md). Budgeted: ~$4,200-4,425/mo. Revenue: soft launch (2026-04-13), tracking toward first paying creators. Break-even (salary + ops): ~188 creators (actual) / ~232 (budgeted). Funding: $240K. Runway: 4.4-5.6 years. | |
| 4 | - | ||
| 5 | - | ## Funding | |
| 6 | - | ||
| 7 | - | Total committed: $190,000. Total reserve: $50,000. Total available: $240,000. | |
| 8 | - | ||
| 9 | - | | Source | Amount | Type | Conditions | | |
| 10 | - | |--------|--------|------|------------| | |
| 11 | - | | Personal savings | $20,000 | Self-funded | None | | |
| 12 | - | | Personal funds (additional) | $20,000 | Self-funded | None | | |
| 13 | - | | Family (parents) | $150,000 | Gift/loan | No strings | | |
| 14 | - | | Family (parents) — reserve | $50,000 | Gift/loan | No strings, draw on request | | |
| 15 | - | ||
| 16 | - | No equity given, no investor obligations, no reporting requirements, no board seats. No repayment schedule. Reserve is separate from the $190K commitment. | |
| 17 | - | ||
| 18 | - | ### Founder Salary | |
| 19 | - | ||
| 20 | - | | Period | Monthly | Annual | Notes | | |
| 21 | - | |--------|---------|--------|-------| | |
| 22 | - | | Months 1-12 | $3,000 | $36,000 | Initial rate | | |
| 23 | - | | Month 13+ | $5,000 | $60,000 | Upgrade contingent on growth; may require additional funding if revenue has not materialized | | |
| 24 | - | ||
| 25 | - | Salary is a business expense (Schedule C or W-2 from LLC, depending on tax election). Included in burn rate calculations below. | |
| 26 | - | ||
| 27 | - | ### Burn Rate & Runway | |
| 28 | - | ||
| 29 | - | | Scenario | Monthly Burn | Committed Runway | With Reserve | | |
| 30 | - | |----------|-------------|------------------|--------------| | |
| 31 | - | | Actual (ops + $3K salary) | $3,580 (per expenses.md) | **4.4 years** | **5.6 years** | | |
| 32 | - | | Budgeted (ops + $3K salary) | ~$4,200-4,425 | **3.6-3.8 years** | **4.5-4.8 years** | | |
| 33 | - | | Year 2+ (ops + $5K salary) | ~$5,580-6,425 | — | — | | |
| 34 | - | ||
| 35 | - | **Actual spend to date: ~$2,000** (launch expenses, 3 months of development). At the Year 1 burn rate ($3,580/mo actual, per expenses.md), committed funding covers **4.4 years**. With reserve: **5.6 years**. | |
| 36 | - | ||
| 37 | - | Year 2 salary upgrade to $5K/mo adds ~$24K/yr. If revenue has not grown to offset this by month 13, additional funding or cost reduction is needed. At $5K salary + full budgeted ops (~$6,425/mo), runway shortens to ~2.5 years committed — still substantial but no longer indefinite. This is the velocity incentive: growth before month 13 determines whether the salary upgrade is self-funding. | |
| 38 | - | ||
| 39 | - | --- | |
| 40 | - | ||
| 41 | - | ## Monthly Operating Costs | |
| 42 | - | ||
| 43 | - | Source: `docs/internal/strategy/tech_costs.md`, `docs/internal/business/economics.md` | |
| 44 | - | ||
| 45 | - | | Category | Low | High | Current Actual | | |
| 46 | - | |----------|-----|------|----------------| | |
| 47 | - | | Infrastructure (Hetzner) | $31 | $31 | $31 | | |
| 48 | - | | Operations | $45 | $80 | ~$5 | | |
| 49 | - | | Business | $834 | $1,114 | ~$337 | | |
| 50 | - | | Development | $200 | $200 | $200 | | |
| 51 | - | | **Total Fixed** | **$1,110** | **$1,425** | **$580 (per expenses.md)** | | |
| 52 | - | ||
| 53 | - | Source: Hetzner invoice 081000817566 (March 2026, $31.00). Current actual is all services billed today. Budgeted range includes Cloudflare Pro ($25), Postmark growth ($15-50), Boulder coworking (~$332), legal reserve ($100-300), and business insurance ($50-100) — expected but not yet active. See `tech_costs.md` for line-item detail. | |
| 54 | - | ||
| 55 | - | --- | |
| 56 | - | ||
| 57 | - | ## Revenue Model | |
| 58 | - | ||
| 59 | - | Source: `docs/internal/business/economics.md`, `docs/internal/strategy/tech_costs.md` | |
| 60 | - | ||
| 61 | - | ### Creator Subscriptions | |
| 62 | - | ||
| 63 | - | | Tier | Price | Variable Cost | Margin | | |
| 64 | - | |------|-------|---------------|--------| | |
| 65 | - | | Basic | $10 | $0.85-1.90 | **$8.10-9.15** | | |
| 66 | - | | Small Files | $20 | $1.90-3.80 | **$16.20-18.10** | | |
| 67 | - | | Big Files | $30 | $3.60-8.60 | **$21.40-26.40** | | |
| 68 | - | | Everything | $60 | $5.00-9.70 | **$50.30-55.00** | | |
| 69 | - | ||
| 70 | - | **Stripe Connect** (Standard accounts): no per-account fees, no payout-volume fees, no per-payout fees charged to the platform. Creators pay Stripe's standard processing fees (~2.9% + $0.30) directly from their own connected accounts. MNW's only Stripe cost is processing on platform subscriptions (creator tier billing). | |
| 71 | - | ||
| 72 | - | ### Fan+ (Consumer Subscription) | |
| 73 | - | ||
| 74 | - | Source: `docs/internal/business/fan-plus.md` | |
| 75 | - | ||
| 76 | - | | Line | Amount | | |
| 77 | - | |------|--------| | |
| 78 | - | | Fan pays | $8.00 | | |
| 79 | - | | Stripe processing | -$0.53 (2.9% + $0.30 per stripe_fees.md) | | |
| 80 | - | | Credit issued | -$5.00 | | |
| 81 | - | | **MNW net per subscriber** | **$2.47** | | |
| 82 | - | ||
| 83 | - | At scale: 100 subs = $247/mo, 500 subs = $1,235/mo, 1,000 subs = $2,470/mo. | |
| 84 | - | ||
| 85 | - | ### App Sync Revenue | |
| 86 | - | ||
| 87 | - | Source: `docs/internal/business/app_sync_pricing.md` | |
| 88 | - | ||
| 89 | - | Desktop apps (GoingsOn, Balanced Breakfast, audiofiles) monetize through SyncKit cloud sync subscriptions. These users are independent of the creator platform — separate acquisition funnels, separate revenue. | |
| 90 | - | ||
| 91 | - | | App | Monthly | Annual | Net/mo (monthly) | Net/mo (annual) | Infra Cost | Margin | | |
| 92 | - | |-----|---------|--------|-------------------|-----------------|------------|--------| | |
| 93 | - | | GoingsOn | $2/mo | $15/yr | ~$1.64 | ~$1.19 | Negligible | ~80%+ | | |
| 94 | - | | Balanced Breakfast | $1/mo | $8/yr | ~$0.67 | ~$0.62 | Negligible | ~90%+ | | |
| 95 | - | | audiofiles (avg) | ~$3/mo | ~$30/yr | ~$2.57 | ~$2.38 | $0.17-3.40 | 58-83% | | |
| 96 | - | ||
| 97 | - | Annual billing is preferred — Stripe fees are disproportionate on small monthly charges (33% on $1/mo vs $0.532/$8 = 6.65% on BB's $8/yr per stripe_fees.md). | |
| 98 | - | ||
| 99 | - | #### Adoption Scenarios | |
| 100 | - | ||
| 101 | - | | Scenario | Timeline | GO users | BB users | AF users (avg $3/mo) | Monthly app revenue | | |
| 102 | - | |----------|----------|----------|----------|----------------------|---------------------| | |
| 103 | - | | Conservative | 6 mo | 50 | 30 | 20 | ~$150 | | |
| 104 | - | | Moderate | 12 mo | 200 | 100 | 50 | ~$545 | | |
| 105 | - | | Optimistic | 18 mo | 500 | 300 | 150 | ~$1,650 | | |
| 106 | - | ||
| 107 | - | GoingsOn is the most likely early driver — productivity apps have higher willingness to pay for sync than feed readers. audiofiles has the highest per-user revenue but the smallest addressable market. | |
| 108 | - | ||
| 109 | - | ### SyncKit SDK (B2B, Future) | |
| 110 | - | ||
| 111 | - | Source: `docs/internal/business/synckit_pricing.md` | |
| 112 | - | ||
| 113 | - | Not yet productized. Revenue from indie developers using SyncKit as sync-as-a-service. Application-based access, no free tier. | |
| 114 | - | ||
| 115 | - | | Mode | Example Config | Monthly Price | | |
| 116 | - | |------|----------------|---------------| | |
| 117 | - | | Simple | 1 GB, 5x burst | $0.30 | | |
| 118 | - | | Simple | 10 GB, 5x burst | $4.50 | | |
| 119 | - | | Builder | 20 GB, 10x burst | $9.00 | | |
| 120 | - | | Builder | 200 GB, 3x burst | $48.00 | | |
| 121 | - | ||
| 122 | - | Infrastructure margin: ~95% on storage, ~67% on transfer. Not modeled in projections until productized. | |
| 123 | - | ||
| 124 | - | --- | |
| 125 | - | ||
| 126 | - | ## Break-Even | |
| 127 | - | ||
| 128 | - | Source: `economics.md`. No Stripe Connect fees on Standard accounts. | |
| 129 | - | ||
| 130 | - | #### Infrastructure-only break-even (ops costs, no salary) | |
| 131 | - | ||
| 132 | - | At current actual ops ($580/mo per expenses.md): | |
| 133 | - | ||
| 134 | - | | Tier Mix | Avg Margin | Creators Needed | | |
| 135 | - | |----------|------------|-----------------| | |
| 136 | - | | Mixed | ~$19.00 | **~30** | | |
| 137 | - | ||
| 138 | - | At budgeted ops (~$1,200/mo): | |
| 139 | - | ||
| 140 | - | | Tier Mix | Avg Margin | Creators Needed | | |
| 141 | - | |----------|------------|-----------------| | |
| 142 | - | | Mixed | ~$19.00 | **~63** | | |
| 143 | - | ||
| 144 | - | #### Full break-even (ops + $3K/mo salary) | |
| 145 | - | ||
| 146 | - | At current actual ops + salary ($3,580/mo per expenses.md): | |
| 147 | - | ||
| 148 | - | | Tier Mix | Avg Margin | Creators Needed | | |
| 149 | - | |----------|------------|-----------------| | |
| 150 | - | | Basic-heavy | ~$8.50 | **~420** | | |
| 151 | - | | Audio-heavy | ~$17.00 | **~210** | | |
| 152 | - | | Video-heavy | ~$24.00 | **~149** | | |
| 153 | - | | Mixed | ~$19.00 | **~188** | | |
| 154 | - | ||
| 155 | - | At budgeted ops + salary (~$4,200/mo): | |
| 156 | - | ||
| 157 | - | | Tier Mix | Avg Margin | Creators Needed | | |
| 158 | - | |----------|------------|-----------------| | |
| 159 | - | | Basic-heavy | ~$8.50 | **~494** | | |
| 160 | - | | Audio-heavy | ~$17.00 | **~247** | | |
| 161 | - | | Video-heavy | ~$24.00 | **~175** | | |
| 162 | - | | Mixed | ~$19.00 | **~221** | | |
| 163 | - | ||
| 164 | - | Infrastructure break-even is easy (~30-63 creators). Full self-sustaining (salary-inclusive) requires ~188-221 creators at mixed tiers — achievable but requires real traction. | |
| 165 | - | ||
| 166 | - | ### Combined Break-Even (Creator Subs + App Sync) | |
| 167 | - | ||
| 168 | - | App sync revenue offsets fixed infrastructure costs, reducing the creator count needed for break-even. | |
| 169 | - | ||
| 170 | - | Using budgeted ops + $3K salary (~$4,200/mo total): | |
| 171 | - | ||
| 172 | - | | App Sync Scenario | App Revenue | Remaining to Cover | Creators Needed (mixed) | | |
| 173 | - | |-------------------|-------------|---------------------|-------------------------| | |
| 174 | - | | None | $0 | ~$4,200 | ~221 | | |
| 175 | - | | Conservative ($150/mo) | ~$150 | ~$4,050 | ~213 | | |
| 176 | - | | Moderate ($545/mo) | ~$545 | ~$3,580 | ~188 | | |
| 177 | - | | Optimistic ($1,650/mo) | ~$1,650 | ~$2,550 | ~134 | | |
| 178 | - | ||
| 179 | - | App sync revenue helps but doesn't transform the picture when salary is included. The real leverage is creator subscriptions — each mixed-tier creator contributes ~$19/mo margin. | |
| 180 | - | ||
| 181 | - | ### Impact on Sustainable / Comfortable Operation | |
| 182 | - | ||
| 183 | - | Using budgeted ops (~$1,200/mo), salary included as target: | |
| 184 | - | ||
| 185 | - | | Target | Creators (subs only) | Creators (with moderate app sync) | | |
| 186 | - | |--------|----------------------|-----------------------------------| | |
| 187 | - | | Ops break-even (no salary) | ~63 | ~31 | | |
| 188 | - | | Ops + $3K salary (Year 1) | ~221 | ~188 | | |
| 189 | - | | Ops + $5K salary (Year 2+) | ~326 | ~294 | | |
| 190 | - | | Ops + $5K + $1K reserve | ~379 | ~346 | | |
| 191 | - | ||
| 192 | - | The Year 2 salary upgrade is the key growth gate. If ~220+ creators are paying by month 13, the $5K salary is self-funding. If not, it draws from reserves — sustainable for ~2.5 years but signals the need for faster growth or cost adjustment. | |
| 193 | - | ||
| 194 | - | --- | |
| 195 | - | ||
| 196 | - | ## Revenue Projections | |
| 197 | - | ||
| 198 | - | Source: `docs/internal/strategy/tech_costs.md` (Cost Projections section) | |
| 199 | - | ||
| 200 | - | Using budgeted costs (~$1,200/mo baseline): | |
| 201 | - | ||
| 202 | - | ### At 100 Creators (Mixed Tiers) | |
| 203 | - | ||
| 204 | - | | Line | Amount | | |
| 205 | - | |------|--------| | |
| 206 | - | | Fixed costs | ~$1,200 | | |
| 207 | - | | Variable costs (~$3 avg) | ~$300 | | |
| 208 | - | | **Total costs** | **~$1,500** | | |
| 209 | - | | Revenue (~$22 avg, per `tier_mix.md`) | ~$2,200 | | |
| 210 | - | | **Surplus** | **~$900** | | |
| 211 | - | ||
| 212 | - | ### At 500 Creators | |
| 213 | - | ||
| 214 | - | | Line | Amount | | |
| 215 | - | |------|--------| | |
| 216 | - | | Fixed costs | ~$1,300 | | |
| 217 | - | | Variable costs | ~$1,500 | | |
| 218 | - | | **Total costs** | **~$2,800** | | |
| 219 | - | | Revenue | ~$12,000 | | |
| 220 | - | | **Surplus** | **~$9,200** | | |
| 221 | - | ||
| 222 | - | ### At 2,000 Creators | |
| 223 | - | ||
| 224 | - | | Line | Amount | | |
| 225 | - | |------|--------| | |
| 226 | - | | Fixed costs | ~$1,600 | | |
| 227 | - | | Variable costs | ~$6,000 | | |
| 228 | - | | **Total costs** | **~$7,600** | | |
| 229 | - | | Revenue | ~$48,000 | | |
| 230 | - | | **Surplus** | **~$40,400** | | |
| 231 | - | ||
| 232 | - | --- | |
| 233 | - | ||
| 234 | - | ## One-Time Investments | |
| 235 | - | ||
| 236 | - | Source: `docs/internal/strategy/pitch.md` | |
| 237 | - | ||
| 238 | - | | Item | Low | High | Status | | |
| 239 | - | |------|-----|------|--------| | |
| 240 | - | | Legal & compliance foundations | $5,750 | $14,350 | Not started | | |
| 241 | - | | Brand & design materials | $400 | $1,050 | Not started | | |
| 242 | - | | Security audit | $2,500 | $6,500 | Not started | | |
| 243 | - | | Community one-time purchases | $609 | $609 | Not started | | |
| 244 | - | | Emergency reserve (6mo) | $4,000 | $4,000 | Not started | | |
| 245 | - | | **Total** | **$13,259** | **$26,509** | | | |
| 246 | - | ||
| 247 | - | Emergency reserve is held, not spent. Legal breakdown: ToS/Privacy ($3-8K), DMCA ($0.5-1K), payment compliance ($2-5K), trademark ($0.25-0.35K + attorney). | |
| 248 | - | ||
| 249 | - | --- | |
| 250 | - | ||
| 251 | - | ## Annual Recurring | |
| 252 | - | ||
| 253 | - | | Item | Low | High | Source | | |
| 254 | - | |------|-----|------|--------| | |
| 255 | - | | Events & travel (6-8 events) | $7,000 | $14,000 | `pitch.md`, `events-2026.md` | | |
| 256 | - | | Outreach recurring subs | $846 | $846 | `budget.md` | | |
| 257 | - | | Outreach capital expansions | $1,700 | $6,500 | `budget.md` | | |
| 258 | - | | Accounting / CPA | $500 | $1,500 | `pitch.md` | | |
| 259 | - | | 1099 filing (via Stripe) | ~$3/creator/yr | ~$3/creator/yr | `pitch.md` | | |
| 260 | - | | **Total (excl. 1099)** | **$10,046** | **$22,846** | | | |
| 261 | - | ||
| 262 | - | Outreach expansions (newsletter sponsorships, jam sponsorships, open source sponsorships, conference micro-presence) were added to `budget.md` after `pitch.md` was written. `pitch.md` only includes ~$1,455 for community building (recurring + one-time). | |
| 263 | - | ||
| 264 | - | --- | |
| 265 | - | ||
| 266 | - | ## Year 1 Total | |
| 267 | - | ||
| 268 | - | | Category | Low | High | | |
| 269 | - | |----------|-----|------| | |
| 270 | - | | Operating (12mo) | $6,876 (actual ops) | $17,100 (budgeted ops) | | |
| 271 | - | | Founder salary (12mo at $3K) | $36,000 | $36,000 | | |
| 272 | - | | One-time investments | $13,259 | $26,509 | | |
| 273 | - | | Annual recurring | $10,046 | $22,846 | | |
| 274 | - | | **Total** | **~$66,181** | **~$102,455** | | |
| 275 | - | ||
| 276 | - | ### Comparison with `pitch.md` | |
| 277 | - | ||
| 278 | - | `pitch.md` estimates Year 1 at **$28,805-49,055**. | |
| 279 | - | ||
| 280 | - | | Delta source | Low | High | | |
| 281 | - | |--------------|-----|------| | |
| 282 | - | | Outreach expansions (added to `budget.md` post-pitch) | +$1,700 | +$6,500 | | |
| 283 | - | | `pitch.md` high-end arithmetic error ($50,055 not $49,055) | — | +$1,000 | | |
| 284 | - | | **Total delta** | **+$1,700** | **+$7,500** | | |
| 285 | - | ||
| 286 | - | The $1,000 arithmetic error: summing `pitch.md` line items gives $50,055 for the high end, not the stated $49,055. | |
| 287 | - | ||
| 288 | - | --- | |
| 289 | - | ||
| 290 | - | ## Revenue-Share Crowdfunding | |
| 291 | - | ||
| 292 | - | **Separate venture.** Not part of core MNW operating costs. Regulatory and legal requirements make this a distinct initiative with its own cost structure. | |
| 293 | - | ||
| 294 | - | Archived — summary in `docs/mnw/todo.md` Deferred section. | |
| 295 | - | ||
| 296 | - | | Item | Year 1 Cost | | |
| 297 | - | |------|-------------| | |
| 298 | - | | Legal / SEC compliance (Reg CF) | ~$75,000 | | |
| 299 | - | | Infrastructure | ~$5,000 | | |
| 300 | - | | **Year 1 total** | **~$80,000** | | |
| 301 | - | ||
| 302 | - | Projected Year 1 revenue: ~$5K. Net: -$75K (investment year). Requires securities attorney, possible FINRA portal registration. Go/no-go gated on initial legal consultation (~$5K). | |
| 303 | - | ||
| 304 | - | --- | |
| 305 | - | ||
| 306 | - | ## Audit Flags | |
| 307 | - | ||
| 308 | - | - [x] Stripe Connect fees missing from `economics.md` and `tech_costs.md` — added to all variable cost tables, break-even, and projections | |
| 309 | - | - [x] Legal reserve overlap unclear — clarified in `tech_costs.md` (ongoing counsel after one-time foundations) | |
| 310 | - | - [x] Fixed cost range vs actual — itemized inactive costs in `tech_costs.md` (insurance, paid monitoring, security scanning, accounting software) | |
| 311 | - | - [x] Break-even numbers in `economics.md` corrected for Standard accounts (no per-account Connect fees) | |
| 312 | - | - [x] `pitch.md` high-end Year 1 total arithmetic error — fixed ($49,055 → $50,055) | |
| 313 | - | - [x] `pitch.md` community building line missing expansion capital — added reference to `budget.md` ($1,700-6,500/yr) | |
| 314 | - | - [x] Stripe Connect corrected from Express to Standard — no per-account, payout-volume, or per-payout fees | |
| 315 | - | - [x] App sync revenue (GO, BB, AF) added to dashboard and economics — adoption scenarios, combined break-even, impact on sustainable operation thresholds | |
| 316 | - | - [x] SyncKit SDK B2B revenue noted as future stream — pricing model documented, not yet in projections | |
| 317 | - | - [x] Coworking expense added ($332/mo Industrious Irvine, active 2026-05-01) | |
| 318 | - | - [x] All cost tables replaced with actual line items from Hetzner invoice + real vendor costs. Speculative ranges replaced with actual/budgeted columns. Hetzner total: $31/mo (was estimated $135-550). Claude Code ($200/mo) added as development cost. Total actual: $580/mo (per expenses.md). All break-even, projections, and Year 1 totals recalculated across financial_dashboard.md, economics.md, and tech_costs.md | |
| 319 | - | ||
| 320 | - | --- | |
| 321 | - | ||
| 322 | - | ## Source Documents | |
| 323 | - | ||
| 324 | - | | File | Location | Contains | | |
| 325 | - | |------|----------|----------| | |
| 326 | - | | economics.md | `docs/internal/business/` | Revenue model, margins, break-even, pricing philosophy | | |
| 327 | - | | tech_costs.md | `docs/internal/strategy/` | Line-item fixed costs, per-tier variable costs, projections at 100/500/2K | | |
| 328 | - | | pitch.md | `docs/internal/strategy/` | Investment summary, Year 1 totals, growth projections, legal/events/brand estimates | | |
| 329 | - | | fan-plus.md | `docs/internal/business/` | Fan+ pricing, unit economics, implementation plan | | |
| 330 | - | | budget.md | `docs/internal/outreach/` | Outreach capital deployment, subscription budget, expansion categories | | |
| 331 | - | | events-2026.md | `docs/internal/strategy/` | Event directory with dates, ticket prices, strategic goals | | |
| 332 | - | | revenue-share-crowdfunding.md | Archived — summary in `docs/mnw/todo.md` Deferred | Separate venture: revenue-share model, Reg CF, financial projections | | |
| 333 | - | | payment-independence.md | `docs/internal/business/` | Payment processing approach, Stripe strategy | | |
| 334 | - | | expenses.md | `docs/internal/business/` | Actual expense ledger, recurring costs, tax categories | | |
| 335 | - | | app_sync_pricing.md | `docs/internal/business/` | App sync pricing (GO, BB, AF), Stripe fee context | | |
| 336 | - | | synckit_pricing.md | `docs/internal/business/` | SyncKit SDK B2B pricing, Simple/Builder modes | | |
| 337 | - | | compliance.md | `docs/internal/business/` | Regulatory compliance requirements | | |
| 338 | - | | mtl.md | `docs/internal/business/` | Money transmitter analysis | | |
| 339 | - | | corporate-structure.md | Archived — summary in `docs/mnw/todo.md` Deferred | Entity structure, state registration | | |
| 340 | - | ||
| 341 | - | --- | |
| 342 | - | ||
| 343 | - | ## Monitor | |
| 344 | - | ||
| 345 | - | - Stripe processing fee changes (current: ~3% on subscriptions, Standard accounts have no Connect fees) | |
| 346 | - | - CDN/bandwidth pricing trends | |
| 347 | - | - Fan+ credit redemption rates (affects net per subscriber: $2.47 if redeemed vs $7.47 if not) | |
| 348 | - | - Business insurance activation timeline and actual cost | |
| 349 | - | - 1099-K threshold changes (thresholds are in flux; see stripe.com/docs/connect/1099-K) | |
| 350 | - | - Outreach budget actual spend vs planned (track which expansions are activated) | |
| 351 | - | - App sync adoption rates by app (GO, BB, AF) — actual vs projected scenarios | |
| 352 | - | - Annual vs monthly billing ratio (annual is higher margin due to Stripe fee structure) | |
| 353 | - | - SyncKit SDK productization timeline and early developer interest |
| @@ -1,120 +0,0 @@ | |||
| 1 | - | # Hetzner Prices — Canonical Reference | |
| 2 | - | ||
| 3 | - | **As of: 2026-05-16.** | |
| 4 | - | **Source: hetzner.com/cloud/, hetzner.com/storage/. Revalidate quarterly or when invoice changes.** | |
| 5 | - | ||
| 6 | - | Every doc that quotes a Hetzner SKU price should cite this file rather than restate the number. EUR prices are the source of truth; USD shown as approximate conversion at €1 ≈ $1.085 (revalidate when FX moves >5%). | |
| 7 | - | ||
| 8 | - | --- | |
| 9 | - | ||
| 10 | - | ## 1. Currently used by MNW | |
| 11 | - | ||
| 12 | - | | SKU | Resources | EUR/mo | USD/mo | Use | | |
| 13 | - | |---|---|---|---|---| | |
| 14 | - | | **CCX13** | 2 dedicated vCPU, 8 GB RAM, 80 GB NVMe | €13.10 | ~$14.00 | Production server (alpha-west-1) | | |
| 15 | - | | **CPX11** ×2 | 2 vCPU AMD shared, 2 GB RAM, 40 GB | €5.49 each | ~$5.96 total | CI runners | | |
| 16 | - | | **Object Storage** (S3-compatible) | 1 TB included, €5.99/TB-month base | €5.99 | ~$6.50 | Backups, static assets | | |
| 17 | - | | **Volumes** | €0.044/GB-month | €0.044/GB | ~$0.048/GB | Attached storage | | |
| 18 | - | | **IPv4** ×3 | Static IP | €0.60/mo each | ~$0.65 each | Production IPs | | |
| 19 | - | | **CCX13 backup** | 20% of instance cost | €2.62 | ~$2.80 | Automated snapshots | | |
| 20 | - | ||
| 21 | - | Current invoice total: ~$31/mo (per `expenses.md`; invoice 081000817566). | |
| 22 | - | ||
| 23 | - | --- | |
| 24 | - | ||
| 25 | - | ## 2. Compute SKU reference (relevant tiers) | |
| 26 | - | ||
| 27 | - | ### Intel shared (CX line) — cheapest | |
| 28 | - | ||
| 29 | - | | SKU | vCPU | RAM | NVMe | EUR/mo | USD/mo | | |
| 30 | - | |---|---|---|---|---|---| | |
| 31 | - | | CX22 | 2 | 4 GB | 40 GB | €4.59 | ~$5.00 | | |
| 32 | - | | CX32 | 4 | 8 GB | 80 GB | €6.49 | ~$7.05 | | |
| 33 | - | | CX42 | 8 | 16 GB | 160 GB | €13.10 | ~$14.20 | | |
| 34 | - | | CX52 | 16 | 32 GB | 320 GB | €25.20 | ~$27.35 | | |
| 35 | - | ||
| 36 | - | ### AMD shared (CPX line) | |
| 37 | - | ||
| 38 | - | | SKU | vCPU | RAM | NVMe | EUR/mo | USD/mo | | |
| 39 | - | |---|---|---|---|---|---| | |
| 40 | - | | CPX11 | 2 | 2 GB | 40 GB | €3.85 | ~$4.18 | | |
| 41 | - | | CPX21 | 3 | 4 GB | 80 GB | €7.55 | ~$8.20 | | |
| 42 | - | | CPX31 | 4 | 8 GB | 160 GB | €13.10 | ~$14.20 | | |
| 43 | - | | CPX41 | 8 | 16 GB | 240 GB | €25.20 | ~$27.35 | | |
| 44 | - | | CPX51 | 16 | 32 GB | 360 GB | €50.40 | ~$54.70 | | |
| 45 | - | ||
| 46 | - | ### Intel dedicated (CCX line) — predictable performance | |
| 47 | - | ||
| 48 | - | | SKU | vCPU | RAM | NVMe | EUR/mo | USD/mo | | |
| 49 | - | |---|---|---|---|---|---| | |
| 50 | - | | CCX13 (in use) | 2 dedicated | 8 GB | 80 GB | €13.10 | ~$14.20 | | |
| 51 | - | | CCX23 | 4 dedicated | 16 GB | 160 GB | €30.00 | ~$32.55 | | |
| 52 | - | | CCX33 | 8 dedicated | 32 GB | 240 GB | €60.50 | ~$65.65 | | |
| 53 | - | | CCX43 | 16 dedicated | 64 GB | 360 GB | €121.00 | ~$131.30 | | |
| 54 | - | | CCX53 | 32 dedicated | 128 GB | 600 GB | €242.00 | ~$262.60 | | |
| 55 | - | ||
| 56 | - | **Common doc errors to avoid:** | |
| 57 | - | - "CX32 ~$15/mo" — wrong, CX32 is ~$7. Likely meant CPX31 (~$15). | |
| 58 | - | - "CX42 ~$30/mo" — wrong, CX42 is ~$14. Likely meant CCX23 (~$32). | |
| 59 | - | ||
| 60 | - | --- | |
| 61 | - | ||
| 62 | - | ## 3. Storage and bandwidth | |
| 63 | - | ||
| 64 | - | | Item | Price | Notes | | |
| 65 | - | |---|---|---| | |
| 66 | - | | Object Storage base | €5.99/TB-month | Includes 1 TB storage | | |
| 67 | - | | Object Storage egress | €1.00/TB | Beyond 1 TB included per bucket | | |
| 68 | - | | Volume (attached block) | €0.044/GB-month | Min 10 GB, max 10 TB per volume | | |
| 69 | - | | Server egress (included) | 1 TB/server/month | Free, on every server | | |
| 70 | - | | Server egress (overage) | €1.00/TB | Beyond included | | |
| 71 | - | ||
| 72 | - | USD per GB references: | |
| 73 | - | - Object storage: ~$0.0065/GB-month | |
| 74 | - | - Egress overage: ~$0.0011/GB | |
| 75 | - | ||
| 76 | - | ### Comparison to AWS (for context only — not used) | |
| 77 | - | ||
| 78 | - | | Item | Hetzner | AWS S3 (Standard) | Multiplier | | |
| 79 | - | |---|---|---|---| | |
| 80 | - | | Storage | $0.0065/GB-mo | $0.023/GB-mo | 3.5× more expensive on AWS | | |
| 81 | - | | Egress | $0.0011/GB (overage) | $0.09/GB | 80× more on AWS | | |
| 82 | - | ||
| 83 | - | --- | |
| 84 | - | ||
| 85 | - | ## 4. Networking and add-ons | |
| 86 | - | ||
| 87 | - | | Item | Price | Notes | | |
| 88 | - | |---|---|---| | |
| 89 | - | | IPv4 (static) | €0.60/mo each | First IP free with server | | |
| 90 | - | | IPv6 | Free | /64 included | | |
| 91 | - | | Load Balancer LB11 | €5.39/mo | Not currently used (Cloudflare free tier handles TLS termination) | | |
| 92 | - | | Load Balancer LB21 | €10.79/mo | — | | |
| 93 | - | | Load Balancer LB31 | €21.59/mo | — | | |
| 94 | - | | Snapshot storage | €0.011/GB-month | — | | |
| 95 | - | | Backup add-on | 20% of server cost | Automated daily snapshots, 7-day retention | | |
| 96 | - | ||
| 97 | - | --- | |
| 98 | - | ||
| 99 | - | ## 5. Regional availability | |
| 100 | - | ||
| 101 | - | MNW production runs in US (Hillsboro, Oregon — "us-west"). Hetzner US regions: | |
| 102 | - | - us-east (Ashburn, VA) — newer, full Cloud product line | |
| 103 | - | - us-west (Hillsboro, OR) — full Cloud product line | |
| 104 | - | ||
| 105 | - | EU regions (Falkenstein/Nuremberg/Helsinki) are not used. | |
| 106 | - | ||
| 107 | - | Latency: us-west to typical US fan is ~30-80ms; Cloudflare edge mitigates further. | |
| 108 | - | ||
| 109 | - | --- | |
| 110 | - | ||
| 111 | - | ## 6. Revalidation checklist | |
| 112 | - | ||
| 113 | - | When updating this file: | |
| 114 | - | ||
| 115 | - | - [ ] Compare current invoice total against `expenses.md` row for Hetzner | |
| 116 | - | - [ ] Confirm SKU prices at hetzner.com/cloud (any new line items or removed SKUs) | |
| 117 | - | - [ ] Confirm Object Storage price at hetzner.com/storage | |
| 118 | - | - [ ] Update EUR→USD conversion if FX has moved >5% | |
| 119 | - | - [ ] Update the as-of date at top | |
| 120 | - | - [ ] Bump downstream docs: `tech_costs.md`, `synckit_pricing.md`, `synckit_vps_separation.md`, `storage_cdn.md`, `infrastructure.md` (public), `economics.md` (public) |
| @@ -1,42 +0,0 @@ | |||
| 1 | - | # Money Transmitter Licenses | |
| 2 | - | ||
| 3 | - | If you receive funds from one party and send them to another, most US states require a money transmitter license (MTL). Internationally, the equivalent goes by different names — payment services license, e-money license — but the idea is the same: governments regulate who can move money. | |
| 4 | - | ||
| 5 | - | Operating without one when you need one is a federal crime. Regulators can fine you, shut you down, or both. Banks won't touch you. | |
| 6 | - | ||
| 7 | - | ## We Don't Need One Today | |
| 8 | - | ||
| 9 | - | Stripe processes all our payments. Funds flow directly from fans to creators through Stripe Connect (Standard accounts). We never receive, hold, or route creator earnings. We're a software platform that uses Stripe's licensed infrastructure — not a payment processor. | |
| 10 | - | ||
| 11 | - | Statutory basis (Colorado, our state of formation): the Money Transmitters Act, C.R.S. Title 11, Article 110 (https://colorado.public.law/statutes/crs_title_11_article_110), defines money transmission as receiving money for transmission. Stripe Connect Standard's structure — connected accounts owned by the creator, funds flowing through Stripe's licensed accounts and never through MNW — keeps MNW outside that definition. See also Stripe's Connect documentation: https://docs.stripe.com/connect/account-capabilities. **Needs lawyer review of CRS 11-110 and a written legal opinion on Stripe Connect Standard MOR posture before launch.** | |
| 12 | - | ||
| 13 | - | ## When That Would Change | |
| 14 | - | ||
| 15 | - | We'd need MTLs if we: | |
| 16 | - | ||
| 17 | - | - Processed payments directly instead of through Stripe | |
| 18 | - | - Held creator funds before payout (escrow, delayed disbursement) | |
| 19 | - | - Operated our own payment rails | |
| 20 | - | - Facilitated direct peer-to-peer transfers | |
| 21 | - | ||
| 22 | - | Any of these would require licensing *before* launch, not after. | |
| 23 | - | ||
| 24 | - | ## What Licensing Looks Like | |
| 25 | - | ||
| 26 | - | **US:** FinCEN registration as a Money Services Business at the federal level, plus individual licenses in 49 states + DC; Montana exempts (per mtl_landscape.md). The process takes 1-2 years and carries ongoing compliance costs (audits, surety bonds, reporting). | |
| 27 | - | ||
| 28 | - | **EU:** Payment Services Directive (PSD2) authorization, or E-Money Directive licensing depending on the model. | |
| 29 | - | ||
| 30 | - | **UK:** FCA authorization for payment services. | |
| 31 | - | ||
| 32 | - | **Canada:** FINTRAC registration plus provincial requirements. | |
| 33 | - | ||
| 34 | - | ## Our Position | |
| 35 | - | ||
| 36 | - | We're not pursuing MTLs now. The Stripe-based model works, serves creators well, and lets us focus on the platform. If we eventually pursue direct payment handling for specific use cases (micro-transactions, creator-to-creator splits — see [Payment Independence](./payment-independence.md)), we'll get licensed first. | |
| 37 | - | ||
| 38 | - | ## See Also | |
| 39 | - | ||
| 40 | - | - [Regulatory Compliance](./compliance.md) — broader compliance overview | |
| 41 | - | - [Payment Independence](./payment-independence.md) — our payment strategy | |
| 42 | - | - [Partnerships](./partnerships.md) — how we choose payment vendors |
| @@ -1,158 +0,0 @@ | |||
| 1 | - | # Money Transmitter Licensing Landscape | |
| 2 | - | ||
| 3 | - | Researched 2026-04-29. Reference document for Phase 24 payment independence planning. | |
| 4 | - | ||
| 5 | - | --- | |
| 6 | - | ||
| 7 | - | ## Bottom Line | |
| 8 | - | ||
| 9 | - | Own MTLs are impractical at MNW's current scale (~$580/month operating costs per `expenses.md`). Full 50-state licensing costs $1.2-2.0M over 5 years. Stripe Connect Standard is the correct approach, and is what every comparable bootstrapped creator platform uses. | |
| 10 | - | ||
| 11 | - | **Important context**: MNW uses Stripe Connect **Standard** (not Express). With Standard accounts, MNW pays zero per-account fees, zero payout-volume fees, and zero per-payout fees. MNW's only Stripe cost is ~3% processing on platform subscriptions. This means the cost pressure to pursue payment independence is almost entirely creator-facing (reducing creators' ~3% processing fees), not platform-facing. The original analysis (before 2026-04-29 correction) assumed Express accounts ($2/account + 0.25% payout volume + $0.25/payout), which would have created urgency that does not actually exist. | |
| 12 | - | ||
| 13 | - | --- | |
| 14 | - | ||
| 15 | - | ## Federal: FinCEN MSB Registration | |
| 16 | - | ||
| 17 | - | - **Trigger**: Any business that transfers funds on behalf of the public. No minimum threshold. | |
| 18 | - | - **Cost**: Free (Form 107 via BSA E-Filing portal). | |
| 19 | - | - **Timeline**: ~2 weeks to appear on MSB registry. | |
| 20 | - | - **Renewal**: Every 2 years. | |
| 21 | - | - **Do NOT register preemptively** — triggers BSA/AML compliance obligations (written program, compliance officer, SAR filing, 5-year record retention). | |
| 22 | - | - Only register if/when MNW begins directly handling money transmission outside of Stripe. | |
| 23 | - | ||
| 24 | - | ## State Licensing | |
| 25 | - | ||
| 26 | - | **49 states + DC** require money transmitter licenses. Montana is the only exception. | |
| 27 | - | ||
| 28 | - | ### Cost summary | |
| 29 | - | ||
| 30 | - | | Scope | Year 1 | Annual ongoing | 5-year total | | |
| 31 | - | |-------|--------|----------------|-------------| | |
| 32 | - | | All states | $400K-770K | $350K-575K | $1.2-2.0M | | |
| 33 | - | | Top 10 states | $100K-200K | $75K-125K | $400K-700K | | |
| 34 | - | | Top 5 states | $50K-100K | $40K-75K | $210K-400K | | |
| 35 | - | ||
| 36 | - | ### Most expensive states | |
| 37 | - | ||
| 38 | - | | State | App fee | Surety bond | Timeline | Source | | |
| 39 | - | |-------|---------|-------------|----------|--------| | |
| 40 | - | | New York | $3,000 application + $15/control person | min $500,000, scaled to volume | 12-24 months | NY DFS: https://www.dfs.ny.gov/apps_and_licensing/money_transmitters and https://www.dfs.ny.gov/apps_and_licensing/application_fee_schedule | | |
| 41 | - | | California | $5,000 | Up to $500K | 12-18 months | CA DFPI new-app checklist: https://mortgage.nationwidelicensingsystem.org/slr/PublishedStateDocuments/CA-DFPI-Money-Transmitter-License-Company-New-App-Checklist.pdf; DFPI Money Transmitters: https://dfpi.ca.gov/regulated-industries/money-transmitters/ | | |
| 42 | - | | Texas | $10,000 | Scaled to volume | 12-18 months | TX DOB MSB page: https://www.dob.texas.gov/money-services-businesses and General Application Requirements: https://www.dob.texas.gov/applications-forms-publications/general-application-requirements | | |
| 43 | - | | Pennsylvania | $5,000 | High (source TBD — see PA DOBS forms) | 12-18 months | PA DOBS Money Transmitters forms: https://www.dobs.pa.gov/Businesses/Non-Bank%20Licensees/Money%20Transmitters/Pages/Money_Transmitters_Forms.aspx | | |
| 44 | - | | Colorado | $7,500 (source TBD — DORA fee schedule) | Variable (statutory bond: see CRS 11-110) | Variable | CO DORA Division of Banking: https://banking.colorado.gov/industry/money-transmitters; statute: https://colorado.public.law/statutes/crs_title_11_article_110 | | |
| 45 | - | ||
| 46 | - | ### Cheapest states | |
| 47 | - | ||
| 48 | - | Montana ($0, no MTL required), Idaho ($100), Tennessee ($250), Utah ($300), Missouri ($300). (source TBD: each state's regulator fee schedule not yet verified in this pass; budget exceeded for one-search-per-claim. Re-verify against NMLS state checklists at https://mortgage.nationwidelicensingsystem.org/SLR/Pages/default.aspx.) | |
| 49 | - | ||
| 50 | - | ### Streamlining mechanisms | |
| 51 | - | ||
| 52 | - | - **NMLS** (Nationwide Multistate Licensing System): Most states accept applications through NMLS. One company record reused across states. | |
| 53 | - | - **MMLA** (Multistate Money Services Licensing Agreement): 23 states participate in coordinated review for 5+ simultaneous applications. | |
| 54 | - | - **MTMA** (Money Transmission Modernization Act): 31 states have adopted, standardizing requirements. Positive trend. | |
| 55 | - | ||
| 56 | - | ### Surety bonds | |
| 57 | - | ||
| 58 | - | - Range: $10K-$500K per state (scaled to transaction volume). Per-state bond amounts are set by state statute; see each state's money-transmitter statute via NMLS State Licensing Requirements: https://mortgage.nationwidelicensingsystem.org/SLR/Pages/default.aspx (source TBD for per-state confirmation under one-search-per-claim budget). | |
| 59 | - | - Annual premium: 1-3% of face value (source TBD: standard surety-bond market rate; cite specific surety quotes if obtained) | |
| 60 | - | - Notable: Florida $50K-$2M, Georgia $100K-$2M, Indiana flat $300K, Massachusetts $100K-$500K (source TBD: each state's MTL statute) | |
| 61 | - | - Total annual premiums across all states (low volume): ~$120K-160K (estimate based on 1-3% × aggregate bond face value) | |
| 62 | - | ||
| 63 | - | ## The Payout-Only Question | |
| 64 | - | ||
| 65 | - | **ACH payouts alone still trigger MTL requirements in most states.** Sending money to creators via ACH counts as money transmission regardless of direction. | |
| 66 | - | ||
| 67 | - | ### Agent of payee exemption | |
| 68 | - | ||
| 69 | - | - 22 states recognize it | |
| 70 | - | - 3 states case-by-case | |
| 71 | - | - ~24 states + DC do not recognize it | |
| 72 | - | - California DFPI explicitly says it does NOT apply to payout transactions | |
| 73 | - | - Not a reliable path for nationwide coverage | |
| 74 | - | ||
| 75 | - | ### How comparable platforms handle this | |
| 76 | - | ||
| 77 | - | | Platform | Approach | Own MTLs? | | |
| 78 | - | |----------|----------|-----------| | |
| 79 | - | | Stripe, PayPal, Square | Licensed money transmitters in all states | Yes (they ARE payment processors) | | |
| 80 | - | | Gumroad, Patreon, Substack, Ko-fi | Route everything through Stripe Connect | No | | |
| 81 | - | | Airbnb, Uber | Agent of payee + MTLs where needed | Partial | | |
| 82 | - | ||
| 83 | - | **Pattern**: Small creator platforms universally rely on Stripe Connect rather than obtaining own licenses. | |
| 84 | - | ||
| 85 | - | ## Alternatives to Own MTLs | |
| 86 | - | ||
| 87 | - | ### Stay on Stripe Connect (recommended, current) | |
| 88 | - | - Cost: $0 incremental | |
| 89 | - | - Stripe holds all necessary US and international licenses | |
| 90 | - | - Limitation: no direct control over payout timing or ACH routing | |
| 91 | - | ||
| 92 | - | ### Stripe Treasury | |
| 93 | - | - Embed financial accounts under Stripe's licenses | |
| 94 | - | - No MTL needed | |
| 95 | - | - Enterprise pricing (likely requires meaningful volume) | |
| 96 | - | - API integration in weeks | |
| 97 | - | ||
| 98 | - | ### Banking-as-a-Service (BaaS) | |
| 99 | - | - Operate under partner bank's charter | |
| 100 | - | - Providers: Unit (https://www.unit.co/), Treasury Prime, Sila Money, Alviere | |
| 101 | - | - Cost: $500-5,000/month base + per-transaction fees (source TBD: Unit and Treasury Prime do not publish per-customer pricing — quotes are bespoke. Industry references suggest minimum monthly commitments in the low-thousands USD range; cite specific quotes when obtained.) | |
| 102 | - | - Risk: BaaS model under increased regulatory scrutiny (Synapse failure) | |
| 103 | - | - No MTL needed | |
| 104 | - | ||
| 105 | - | ### Licensed payout partners | |
| 106 | - | - Tipalti (https://tipalti.com/pricing/), Hyperwallet (PayPal), Payoneer (https://www.payoneer.com/about/pricing/) handle payouts under their licenses | |
| 107 | - | - Tipalti: subscription base + per-transaction fees; not publicly published — quote required (https://tipalti.com/pricing/). Third-party references cite ~$0.40 domestic ACH and ~$26 international SWIFT wire (source TBD: confirm via Tipalti quote). | |
| 108 | - | - Payoneer Mass Payouts: 1% of transaction per their published pricing (https://www.payoneer.com/about/pricing/), with regional variation | |
| 109 | - | - No MTL needed | |
| 110 | - | ||
| 111 | - | ## International | |
| 112 | - | ||
| 113 | - | ### EU (PSD2) | |
| 114 | - | - Payment Institution license required, passportable across EU (Directive (EU) 2015/2366; https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32015L2366) | |
| 115 | - | - Small PI registration available for <EUR 3M/month (source TBD: confirm thresholds with EBA/national regulator — varies by member state) | |
| 116 | - | - Cost: EUR 50K-200K including legal (source TBD: estimate, varies by member state and applicant; cite specific quote when obtained) | |
| 117 | - | - Timeline: 3-12 months | |
| 118 | - | - **Not practical at MNW's scale. Stripe Connect covers EU obligations.** | |
| 119 | - | ||
| 120 | - | ### UK (FCA) | |
| 121 | - | - Separate from EU post-Brexit | |
| 122 | - | - Small Payment Institution registration available | |
| 123 | - | - 6-12 months for authorized PI | |
| 124 | - | - **Not practical. Stripe covers UK.** | |
| 125 | - | ||
| 126 | - | ### Canada (FINTRAC) | |
| 127 | - | - MSB registration is free | |
| 128 | - | - Must implement AML compliance program | |
| 129 | - | - Bank of Canada registration also required (RPAA) | |
| 130 | - | - **Least burdensome international option, but Stripe covers it.** | |
| 131 | - | ||
| 132 | - | ### Bottom line on international | |
| 133 | - | Stripe Connect handles all international payment compliance. As long as MNW uses Connect, international licensing is Stripe's problem. | |
| 134 | - | ||
| 135 | - | ## Decision Framework | |
| 136 | - | ||
| 137 | - | With Standard accounts, MNW's Stripe costs are negligible (~3% of platform subscriptions only). The decision to pursue payment alternatives is driven by creator-side benefits, not MNW cost pressure. | |
| 138 | - | ||
| 139 | - | | Scale | Approach | Why | | |
| 140 | - | |-------|----------|-----| | |
| 141 | - | | <$50K/month GMV | Stripe Connect Standard | Zero Connect fees, compliant, what everyone uses | | |
| 142 | - | | Any scale | Stripe ACH payment method | Offer fans 0.8% ACH option at checkout — reduces creator fees, no MTL needed, just a Stripe feature | | |
| 143 | - | | >200 creators | Document Stripe contingency plan | Mitigate single-vendor dependency risk | | |
| 144 | - | | Creator demand | BaaS for unsupported countries | Serve creators where Stripe doesn't operate | | |
| 145 | - | | >$2M/month GMV | Consider own MTLs in top states | Revenue justifies $75K-125K/year compliance | | |
| 146 | - | | >$10M/month GMV | Full 50-state licensing | Revenue justifies $350K-575K/year compliance | | |
| 147 | - | ||
| 148 | - | ## Sources | |
| 149 | - | ||
| 150 | - | - FinCEN MSB Registration: fincen.gov/resources/money-services-business-msb-registration | |
| 151 | - | - FinCEN BSA Requirements: fincen.gov/bsa-requirements-msbs | |
| 152 | - | - CSBS NMLS: csbs.org/nationwide-multistate-licensing-system-nmls | |
| 153 | - | - CSBS MMLA (23 states): csbs.org/newsroom/23-states-join-multistate-licensing-agreement | |
| 154 | - | - CSBS MTMA (31 states): csbs.org/csbs-money-transmission-modernization-act-mtma | |
| 155 | - | - CSBS Agent of Payee Map: csbs.org/agent-payee-exemption-map | |
| 156 | - | - CA DFPI Payout Guidance: dfpi.ca.gov/2019/07/01/receiving-money-for-transmission | |
| 157 | - | - Stripe Treasury: stripe.com/treasury/platforms | |
| 158 | - | - Cost modeling: brico.ai/post/how-much-do-mtls-cost, remitso.com/blogs/money-transmitter-license |
| @@ -1,284 +0,0 @@ | |||
| 1 | - | # Partnership Targets | |
| 2 | - | ||
| 3 | - | Potential partners organized by relationship type. See [partnerships.md](./partnerships.md) for principles. | |
| 4 | - | ||
| 5 | - | ## Mutual Endorsement | |
| 6 | - | ||
| 7 | - | Organizations whose stated values appear aligned with ours where the relationship is reciprocal visibility. We recommend them, they recommend us. (Subjective alignment based on public statements — verify in conversation before any reciprocal commitment.) | |
| 8 | - | ||
| 9 | - | ### Sourcehut | |
| 10 | - | ||
| 11 | - | Drew DeVault's source hosting. Self-funded, no VC, no tracking, sustainable pricing, builds-as-a-service. We already use it. Publicly stated values overlap substantially with ours. Small enough that mutual endorsement is meaningful in both directions. | |
| 12 | - | ||
| 13 | - | Contact: Direct to Drew DeVault. | |
| 14 | - | ||
| 15 | - | ### Ghost Foundation | |
| 16 | - | ||
| 17 | - | Nonprofit (legally cannot be bought or sold). Open source publishing platform. $10M+ annual revenue, all reinvested. No ads, no VC, no shareholders. Publishes financials publicly. They take a percentage rather than flat fee — different fee model, but values overlap substantially in other respects. | |
| 18 | - | ||
| 19 | - | Contact: Direct outreach. They have an integrations ecosystem worth exploring technically. | |
| 20 | - | ||
| 21 | - | ### Buttondown | |
| 22 | - | ||
| 23 | - | Bootstrapped newsletter platform. "Funded by our customers." Tracking is opt-in. Full data export. No extractive free tier. Public values language overlaps with ours. | |
| 24 | - | ||
| 25 | - | Contact: Direct to founder Justin Duke. | |
| 26 | - | ||
| 27 | - | ### Micro.blog | |
| 28 | - | ||
| 29 | - | Chronological feed, no algorithm, no ads, no follower counts, no like counts, no virality mechanics. Indie web community. Subscription model. Promotes creator-owned domains over platform lock-in. | |
| 30 | - | ||
| 31 | - | Contact: Direct to founder Manton Reece. | |
| 32 | - | ||
| 33 | - | ### Write.as | |
| 34 | - | ||
| 35 | - | Privacy-by-default publishing. No personal data collection. Open web standards (RSS, ActivityPub). Owner-operated since 2015, no exit interest. | |
| 36 | - | ||
| 37 | - | Contact: Direct to founder Matt Baer. | |
| 38 | - | ||
| 39 | - | ### Small Technology Foundation | |
| 40 | - | ||
| 41 | - | Aral Balkan's org. Rejects VC, builds "stayups not startups." Privacy-first, copyleft. Coined the "small technology" framing that describes what we're doing. Aral actively amplifies aligned projects. | |
| 42 | - | ||
| 43 | - | Contact: Direct to Aral Balkan. | |
| 44 | - | ||
| 45 | - | ### Codeberg | |
| 46 | - | ||
| 47 | - | Nonprofit community-led code hosting. No tracking, no third-party cookies. Community has voting rights. Direct alternative to GitHub's increasingly VC-adjacent model. | |
| 48 | - | ||
| 49 | - | Contact: Organizational membership. | |
| 50 | - | ||
| 51 | - | ### 37signals (Basecamp / HEY) | |
| 52 | - | ||
| 53 | - | The canonical bootstrapped, anti-VC, "calm company" tech business. Jason Fried and DHH are vocal advocates who have publicly promoted aligned companies. No formal program, but they endorse peers. | |
| 54 | - | ||
| 55 | - | Contact: Cold outreach. They've signal-boosted aligned projects before. | |
| 56 | - | ||
| 57 | - | ### itch.io | |
| 58 | - | ||
| 59 | - | Open revenue sharing (creators choose their own fee, including 0%). No approval gatekeeping. Pay-what-you-want. Ad-free. "We do not believe in exploiting content." $1B+ distributed to indie game creators. Privately held. | |
| 60 | - | ||
| 61 | - | Contact: Direct outreach. They co-sponsor indie creator events. | |
| 62 | - | ||
| 63 | - | ### Obsidian | |
| 64 | - | ||
| 65 | - | 100% user-funded, no investors. Local-first, privacy-by-default, data on your device, fully exportable. "Your thoughts belong to you." No algorithm. | |
| 66 | - | ||
| 67 | - | Contact: Community spotlights, direct outreach. | |
| 68 | - | ||
| 69 | - | ### Kagi | |
| 70 | - | ||
| 71 | - | Subscription-only search. No ads, no profiling, no tracking. "We answer to you." No investor pressure. Anti-algorithmic-manipulation. Same structural argument we make. | |
| 72 | - | ||
| 73 | - | Contact: Direct outreach for co-promotion. | |
| 74 | - | ||
| 75 | - | --- | |
| 76 | - | ||
| 77 | - | ## Offer Free Infrastructure | |
| 78 | - | ||
| 79 | - | Organizations doing aligned work where we could host their content, community, or distribution on MNW at no cost. Gets real usage from credible orgs, demonstrates the platform, and creates a genuine relationship. | |
| 80 | - | ||
| 81 | - | ### Oxide Computer | |
| 82 | - | ||
| 83 | - | Bryan Cantrill's company. Radical transparency, anti-lock-in, engineering-values-first. Could host community content, blog, tutorials. | |
| 84 | - | ||
| 85 | - | ### Prusa Research | |
| 86 | - | ||
| 87 | - | Bootstrapped, no investors, open source 3D printing. "Open source is our heart." Maker/creator community. Could host their maker content, guides, sample files. | |
| 88 | - | ||
| 89 | - | ### REAPER (Cockos) | |
| 90 | - | ||
| 91 | - | DRM-free perpetual-license DAW. $60 discounted/$225 commercial. No subscription extraction. Independent, bootstrapped. The anti-Adobe of audio tools. Could host tutorials, presets, user-contributed content. | |
| 92 | - | ||
| 93 | - | ### Ardour | |
| 94 | - | ||
| 95 | - | Open source DAW built by musicians. Could host community content, tutorials, templates. | |
| 96 | - | ||
| 97 | - | --- | |
| 98 | - | ||
| 99 | - | ## Formal Partner Programs | |
| 100 | - | ||
| 101 | - | Organizations with existing partnership or sponsorship programs we can apply to. | |
| 102 | - | ||
| 103 | - | ### Framework | |
| 104 | - | ||
| 105 | - | Right-to-repair laptops. Community partner program exists. "Own your hardware" maps directly onto "own your platform." Their audience (people who deliberately chose repairability over convenience) is our audience. | |
| 106 | - | ||
| 107 | - | Action: Prepare application to community partner program. | |
| 108 | - | ||
| 109 | - | ### Proton (Mail/VPN/Drive) | |
| 110 | - | ||
| 111 | - | "We can't enshittify because of how we're structured." Privacy-first, Swiss jurisdiction, open source. Has community/partner programs. | |
| 112 | - | ||
| 113 | - | Action: Prepare application. | |
| 114 | - | ||
| 115 | - | ### Nextcloud | |
| 116 | - | ||
| 117 | - | "Restore digital sovereignty." 100% open source. Full data control. Has a formal channel partner program. | |
| 118 | - | ||
| 119 | - | Action: Prepare application. | |
| 120 | - | ||
| 121 | - | ### EFF (Electronic Frontier Foundation) | |
| 122 | - | ||
| 123 | - | Digital rights, privacy, anti-surveillance. Formal Corporate Giving & Sponsorships program. Companies get an EFF Supporter badge. Current members include DuckDuckGo, Fastly, Matomo. | |
| 124 | - | ||
| 125 | - | Action: Contact partnerships team. Even a small organizational membership gets the badge and the association. | |
| 126 | - | ||
| 127 | - | ### Software Freedom Conservancy | |
| 128 | - | ||
| 129 | - | Defends copyleft, right-to-repair for software, anti-lock-in. Formal sponsor program with logo placement. Mozilla Foundation is a current sponsor. | |
| 130 | - | ||
| 131 | - | Action: Apply to sponsor program. | |
| 132 | - | ||
| 133 | - | --- | |
| 134 | - | ||
| 135 | - | ## Digital Rights and Advocacy | |
| 136 | - | ||
| 137 | - | Organizations where the relationship is closer to membership or mutual support than commercial partnership. | |
| 138 | - | ||
| 139 | - | ### Creative Commons | |
| 140 | - | ||
| 141 | - | 25 years of legal infrastructure for creator rights. "Connective tissue of the open ecosystem." Champions attribution and creator control. | |
| 142 | - | ||
| 143 | - | Contact: Open Infrastructure Circle donor program. | |
| 144 | - | ||
| 145 | - | ### Internet Archive | |
| 146 | - | ||
| 147 | - | Digital preservation, open access, anti-lock-in. Active Mastodon sponsor. Mission aligns with our data sovereignty stance. | |
| 148 | - | ||
| 149 | - | Contact: Organizational supporter program. | |
| 150 | - | ||
| 151 | - | ### FSFE (Free Software Foundation Europe) | |
| 152 | - | ||
| 153 | - | More pragmatic than FSF-US. "Public Money, Public Code" campaign. Data sovereignty focus. Has a Fellows and Supporter program for organizations. | |
| 154 | - | ||
| 155 | - | ### iFixit | |
| 156 | - | ||
| 157 | - | Right-to-repair advocacy and parts. "Repair changes the world." Same ownership philosophy we apply to data and platforms. Kyle Wiens (CEO) is vocal and media-savvy. | |
| 158 | - | ||
| 159 | - | Contact: Direct to Kyle Wiens. They co-market with aligned brands. | |
| 160 | - | ||
| 161 | - | --- | |
| 162 | - | ||
| 163 | - | ## Privacy-Aligned Tech | |
| 164 | - | ||
| 165 | - | Companies whose privacy-first positioning creates natural audience overlap. | |
| 166 | - | ||
| 167 | - | ### Mullvad | |
| 168 | - | ||
| 169 | - | No accounts, no email required. Hardcore privacy. Their users are the people who read our source code before signing up. | |
| 170 | - | ||
| 171 | - | ### Tuta (formerly Tutanota) | |
| 172 | - | ||
| 173 | - | Open source encrypted email. No ads, no tracking, renewable energy. Protects journalists and whistleblowers. Independent, not VC-backed. Has nonprofit/school discounts, likely open to aligned partnerships. | |
| 174 | - | ||
| 175 | - | ### Fastmail | |
| 176 | - | ||
| 177 | - | Independent email, anti-Google, sustainable business. Similar "boring sustainable infrastructure" positioning. | |
| 178 | - | ||
| 179 | - | ### DuckDuckGo | |
| 180 | - | ||
| 181 | - | No search tracking. EFF organizational member. Note: has taken some outside investment, so verify current alignment. | |
| 182 | - | ||
| 183 | - | ### Purism | |
| 184 | - | ||
| 185 | - | Social Purpose Corporation (legally binding ethical commitments). Open source hardware and software. Privacy-first. Has turned down acquisition offers. | |
| 186 | - | ||
| 187 | - | ### Nitrokey | |
| 188 | - | ||
| 189 | - | Open source hardware security keys. Self-financed, mission-driven, full transparency. | |
| 190 | - | ||
| 191 | - | --- | |
| 192 | - | ||
| 193 | - | ## Hardware / Maker | |
| 194 | - | ||
| 195 | - | ### System76 | |
| 196 | - | ||
| 197 | - | Open source hardware/software (Pop!_OS). "Your computer is yours." Right-to-repair ethos. | |
| 198 | - | ||
| 199 | - | ### Fairphone | |
| 200 | - | ||
| 201 | - | Modular, repairable, 8+ year software support. Ethical manufacturing. iFixit certified. Already collaborates with privacy-focused OS providers. | |
| 202 | - | ||
| 203 | - | ### PINE64 | |
| 204 | - | ||
| 205 | - | Community-run open hardware. "FOSS principles guide our business." Non-profit adjacent governance. | |
| 206 | - | ||
| 207 | - | ### Teenage Engineering | |
| 208 | - | ||
| 209 | - | Design-forward, anti-commodity. Makes tools for independent musicians and creators. Their audience is our audience. | |
| 210 | - | ||
| 211 | - | ### RODE | |
| 212 | - | ||
| 213 | - | Heavily invested in supporting independent creators. Runs competitions, sponsors podcasters and musicians. | |
| 214 | - | ||
| 215 | - | --- | |
| 216 | - | ||
| 217 | - | ## Ethical Consumer Brands | |
| 218 | - | ||
| 219 | - | Companies where the connection is values-based, not technical. Better suited for post-launch when we have audience. | |
| 220 | - | ||
| 221 | - | ### Patagonia | |
| 222 | - | ||
| 223 | - | Anti-corporate, environmental, values-driven. Sponsors aligned projects and causes. | |
| 224 | - | ||
| 225 | - | ### Dr. Bronner's | |
| 226 | - | ||
| 227 | - | B-corp, radical transparency, auditable supply chain. "Every claim is verifiable" maps to our source-available stance. | |
| 228 | - | ||
| 229 | - | ### DFTBA Records | |
| 230 | - | ||
| 231 | - | Hank Green's creator-owned merch and distribution company. Exists because creators got tired of middlemen. Non-tech analog to what we're building. | |
| 232 | - | ||
| 233 | - | ### Darn Tough / Leatherman | |
| 234 | - | ||
| 235 | - | "Buy once, own forever" brands. Lifetime warranty. Anti-planned-obsolescence. The physical-goods version of our anti-extraction argument. | |
| 236 | - | ||
| 237 | - | ### Ethical Consumer (UK) | |
| 238 | - | ||
| 239 | - | Not-for-profit cooperative. Rates 40,000+ brands on ethical criteria. Getting reviewed/featured by them is a trust signal. | |
| 240 | - | ||
| 241 | - | --- | |
| 242 | - | ||
| 243 | - | ## Creator Tool Companies | |
| 244 | - | ||
| 245 | - | ### Literature and Latte (Scrivener) | |
| 246 | - | ||
| 247 | - | By writers, for writers. No aggressive subscription model. "Tools adapt to you." Strong author/screenwriter community. | |
| 248 | - | ||
| 249 | - | --- | |
| 250 | - | ||
| 251 | - | ## Cooperative Networks | |
| 252 | - | ||
| 253 | - | ### Loomio | |
| 254 | - | ||
| 255 | - | Worker cooperative, open source. Democratic governance in product and company. One of the most structurally aligned cooperative tech businesses. | |
| 256 | - | ||
| 257 | - | ### CoTech (Cooperative Technologists) | |
| 258 | - | ||
| 259 | - | UK network of worker cooperatives building ethical tech. Gateway to the cooperative tech ecosystem. | |
| 260 | - | ||
| 261 | - | ### Open Collective | |
| 262 | - | ||
| 263 | - | Community-governed financial infrastructure for open source. Transitioned from startup to nonprofit. Anti-extraction model. | |
| 264 | - | ||
| 265 | - | --- | |
| 266 | - | ||
| 267 | - | ## Do Not Pursue | |
| 268 | - | ||
| 269 | - | - **Substack** -- VC-funded, content moderation controversies, misaligned incentives | |
| 270 | - | - **Gumroad** -- VC history, profitability-at-all-costs public statements | |
| 271 | - | - **Patreon** -- VC-backed, growing fees, enshittification case study | |
| 272 | - | - **Bandcamp** -- Values were excellent but corporate situation is uncertain post-Songtradr acquisition. Monitor. | |
| 273 | - | ||
| 274 | - | --- | |
| 275 | - | ||
| 276 | - | ## Sequencing | |
| 277 | - | ||
| 278 | - | Group by phase rather than ranked priority — no rubric exists yet to justify intra-group ordering. | |
| 279 | - | ||
| 280 | - | Near-term (pre-launch, relationship-building): FUTO, EFF, Sourcehut, Ghost Foundation, Buttondown, Micro.blog, Write.as. | |
| 281 | - | ||
| 282 | - | Medium-term (soft launch, first creators onboarded): Framework, Proton, Nextcloud, iFixit, Small Technology Foundation, 37signals, Kagi, Obsidian. | |
| 283 | - | ||
| 284 | - | Post-launch (established audience): Patagonia, Dr. Bronner's, DFTBA, ethical consumer brands; hardware (System76, Fairphone, PINE64); cooperative networks. |
| @@ -1,48 +0,0 @@ | |||
| 1 | - | # Partnerships | |
| 2 | - | ||
| 3 | - | We'll work with organizations that align with what we're building. We won't work with ones that don't. | |
| 4 | - | ||
| 5 | - | ## What This Means in Practice | |
| 6 | - | ||
| 7 | - | A good partner is an organization we'd recommend to a creator even if we had no business relationship with them. They don't monetize user data, they don't use dark patterns, and they don't treat creators as a resource to extract from. | |
| 8 | - | ||
| 9 | - | We're interested in: | |
| 10 | - | ||
| 11 | - | - **Non-profits** in creator advocacy, digital rights, or open source | |
| 12 | - | - **Creator collectives and studios** doing real work for their members | |
| 13 | - | - **Complementary tools** that don't exploit their users | |
| 14 | - | - **Open source projects** we depend on or integrate with | |
| 15 | - | - **Educational programs** teaching creative skills | |
| 16 | - | ||
| 17 | - | We're not interested in organizations that lock users in, surveil them, or have a track record of mistreating creators or workers. If we find out a partner does these things after we've started working together, we stop working with them. | |
| 18 | - | ||
| 19 | - | ## Sponsorship | |
| 20 | - | ||
| 21 | - | We may accept in-kind sponsorship for infrastructure costs — servers, storage, bandwidth. Sponsors get their name on a clearly marked sponsorship page. That's it. | |
| 22 | - | ||
| 23 | - | Sponsors don't get placement in the product, access to user data, roadmap influence, or policy exceptions. The sponsorship page is acknowledgment, not advertising. | |
| 24 | - | ||
| 25 | - | ## Integration | |
| 26 | - | ||
| 27 | - | For organizations doing work we respect, we're open to technical integrations, sharing audiences where it helps creators, or collaborating on shared problems. | |
| 28 | - | ||
| 29 | - | ## We Own Our Complexity | |
| 30 | - | ||
| 31 | - | We have a deliberate bias toward doing things ourselves. We run our own infrastructure, build our own integrations, and avoid vendor lock-in even when the managed alternative would be easier. | |
| 32 | - | ||
| 33 | - | When we do use external services, we pick them for transparent pricing, open standards, and business practices we're comfortable with. See [economics.md](./economics.md) for what this looks like in practice. | |
| 34 | - | ||
| 35 | - | ## Contact | |
| 36 | - | ||
| 37 | - | [partnerships@makenot.work](mailto:partnerships@makenot.work) | |
| 38 | - | ||
| 39 | - | We read everything. We don't respond to pitches that clearly didn't read this page. | |
| 40 | - | ||
| 41 | - | ## See Also | |
| 42 | - | ||
| 43 | - | - [Partnership Targets](./partnership-targets.md) — specific organizations we want to work with | |
| 44 | - | - [How We Work](../../public/about/how-we-work.md) — business model and pricing | |
| 45 | - | - [Service Level Agreement](../../public/about/guarantees.md) — binding commitments | |
| 46 | - | - [Payment Independence](./payment-independence.md) — our approach to payment vendors | |
| 47 | - | - [Roadmap](../../public/about/roadmap.md) — what we're building and how | |
| 48 | - | - [Economics](./economics.md) — why we prefer owning complexity |
| @@ -1,65 +0,0 @@ | |||
| 1 | - | # Payment Independence | |
| 2 | - | ||
| 3 | - | We use Stripe for everything today. That's fine for now, but long-term we want creators to have options. | |
| 4 | - | ||
| 5 | - | ## Current State: Stripe | |
| 6 | - | ||
| 7 | - | All payments run through Stripe: | |
| 8 | - | ||
| 9 | - | - **Fan purchases and subscriptions** go through Stripe Checkout | |
| 10 | - | - **Creator payouts** go through Stripe Connect — funds land in the creator's own Stripe account, not ours | |
| 11 | - | - **Platform billing** (creator subscriptions to us) is also Stripe | |
| 12 | - | ||
| 13 | - | Fan pays ~2.9% + $0.30 per transaction. That fee is Stripe's — we don't add anything on top. Creators control their own payout timing. We never hold funds. | |
| 14 | - | ||
| 15 | - | ### Why Stripe First | |
| 16 | - | ||
| 17 | - | Building payment infrastructure from scratch would have delayed the platform by months. Stripe gave us global reach (46+ countries, per stripe.com/global), direct-to-creator payouts, and a processor fans already trust. The tradeoff is that we depend on a single vendor and eat their fee structure. | |
| 18 | - | ||
| 19 | - | ## Where We Want to Go | |
| 20 | - | ||
| 21 | - | The goal is to give creators cheaper ways to get paid, starting with payouts (where the fees hurt most) and working toward intake. | |
| 22 | - | ||
| 23 | - | **Payout alternatives (next priority):** | |
| 24 | - | ||
| 25 | - | - ACH direct deposit for US creators who don't need instant access | |
| 26 | - | - SEPA transfers for EU creators | |
| 27 | - | - Crypto for creators who want it — with honest disclosure about volatility and tax complexity | |
| 28 | - | - Country-specific payment rails where they're cheaper than Stripe | |
| 29 | - | ||
| 30 | - | **Intake alternatives (longer term):** | |
| 31 | - | ||
| 32 | - | - Lower-cost processors for specific transaction types | |
| 33 | - | - Regional processors where they beat Stripe on price | |
| 34 | - | - Direct bank payments (ACH/SEPA) for fans who prefer them | |
| 35 | - | ||
| 36 | - | **Own infrastructure (eventually, maybe):** | |
| 37 | - | ||
| 38 | - | - Micro-transactions where percentage fees eat the payment | |
| 39 | - | - Creator-to-creator splits without double-dipping on fees | |
| 40 | - | - Batch processing for high-volume creators | |
| 41 | - | ||
| 42 | - | This last step requires money transmitter licenses in 49 states + DC; Montana exempts, and 1-2 years of regulatory work. We're not doing it until the math justifies it. See [mtl.md](./mtl.md) for details. | |
| 43 | - | ||
| 44 | - | ## What We Won't Do | |
| 45 | - | ||
| 46 | - | **Hold creator funds.** Money goes directly to creator accounts. This is structural, not a courtesy — we never want to be in a position where we're sitting on someone else's earnings. | |
| 47 | - | ||
| 48 | - | **Obscure fees.** You see what Stripe charges. | |
| 49 | - | ||
| 50 | - | **Lock you in.** Your Stripe account is yours. Your customer relationships are yours. If you leave, you take them with you. | |
| 51 | - | ||
| 52 | - | ## Unsupported Countries | |
| 53 | - | ||
| 54 | - | Stripe doesn't operate everywhere. If you're in a country without Stripe support, contact us — we track demand by region and it influences which alternative processors we evaluate first. | |
| 55 | - | ||
| 56 | - | ## Timeline | |
| 57 | - | ||
| 58 | - | We don't give timeline predictions for payment infrastructure. The regulatory surface is large and the consequences of getting it wrong are serious. Stripe works now and will keep working. We'll announce alternatives as they're ready. | |
| 59 | - | ||
| 60 | - | ## See Also | |
| 61 | - | ||
| 62 | - | - [Economics](./economics.md) — where payment costs fit in our model | |
| 63 | - | - [Money Transmitter Licenses](./mtl.md) — regulatory requirements for direct payment handling | |
| 64 | - | - [Partnerships](./partnerships.md) — how we choose vendors | |
| 65 | - | - [Roadmap](../../public/about/roadmap.md) — broader platform roadmap |
| @@ -1,170 +0,0 @@ | |||
| 1 | - | # Pricing | |
| 2 | - | ||
| 3 | - | **Status: draft — open decisions at the end.** | |
| 4 | - | **As of: 2026-05-16. Update on every price-affecting change.** | |
| 5 | - | ||
| 6 | - | How we decide what to charge, what we charge today, and what gets published to creators. | |
| 7 | - | ||
| 8 | - | This doc is internal. The creator-facing version is a short page derived from this one (see §6). | |
| 9 | - | ||
| 10 | - | --- | |
| 11 | - | ||
| 12 | - | ## 1. Current prices | |
| 13 | - | ||
| 14 | - | Two rates run in parallel. | |
| 15 | - | ||
| 16 | - | ### Founding-creator rate (launch — first cohort) | |
| 17 | - | ||
| 18 | - | | Tier | Price | | |
| 19 | - | |---|---| | |
| 20 | - | | Basic | **$5/mo** | | |
| 21 | - | | Small Files | **$10/mo** | | |
| 22 | - | | Big Files | **$15/mo** | | |
| 23 | - | | Everything | **$30/mo** | | |
| 24 | - | ||
| 25 | - | These are 50% of standard rates. They are not framed as a discount. They are the launch prices. | |
| 26 | - | ||
| 27 | - | ### Standard rate (post-cohort — provisional) | |
| 28 | - | ||
| 29 | - | | Tier | Price | | |
| 30 | - | |---|---| | |
| 31 | - | | Basic | $10/mo | | |
| 32 | - | | Small Files | $20/mo | | |
| 33 | - | | Big Files | $30/mo | | |
| 34 | - | | Everything | $60/mo | | |
| 35 | - | ||
| 36 | - | These are provisional. They are the rate that applies to new signups *after* the founding cohort closes. They will be reset when the cohort closes, based on measured cost data, signup velocity, and reserve health. They may stay where they are, drop, or rise — but they will never rise without 90 days notice and grandfathering per `guarantees.md`. | |
| 37 | - | ||
| 38 | - | --- | |
| 39 | - | ||
| 40 | - | ## 2. Founding cohort definition | |
| 41 | - | ||
| 42 | - | **Cap (whichever happens first):** | |
| 43 | - | - First **500** creator subscriptions, or | |
| 44 | - | - First **12 months** of public availability (i.e., post-alpha launch). | |
| 45 | - | ||
| 46 | - | The cap is a hard structural limit, not a marketing deadline. Once hit, the cohort closes. New signups pay the standard rate. | |
| 47 | - | ||
| 48 | - | **Lock duration:** Founding rate is locked for the lifetime of an uninterrupted subscription. If a founding creator cancels and later resubscribes, they pay the rate in effect at resubscription (not necessarily founding rate). | |
| 49 | - | ||
| 50 | - | **Tier mobility within founding rate:** A founding creator can upgrade or downgrade between tiers and stay on founding rates for any tier. The lock attaches to the *creator*, not to the specific tier. | |
| 51 | - | ||
| 52 | - | **No referral mechanic in the cohort:** A founding creator cannot transfer founding status. The cohort fills based on signup order, not on social structure. | |
| 53 | - | ||
| 54 | - | --- | |
| 55 | - | ||
| 56 | - | ## 3. Grandfathering rules | |
| 57 | - | ||
| 58 | - | Once a creator has any active subscription rate locked in, that rate cannot rise as long as the subscription stays active. This applies to founding rates *and* to any standard rate the creator was paying when standard rates were last set. | |
| 59 | - | ||
| 60 | - | If standard rates fall, existing subscribers fall with them (cost-favorable changes apply retroactively to active subs). If standard rates rise, existing subscribers stay on their locked-in rate per `guarantees.md`. | |
| 61 | - | ||
| 62 | - | Standard rate changes apply only to new signups and to creators who allow their subscription to lapse and resubscribe. | |
| 63 | - | ||
| 64 | - | --- | |
| 65 | - | ||
| 66 | - | ## 4. How prices change | |
| 67 | - | ||
| 68 | - | Price changes are *not* formula-driven. There is no public trigger that says "if $X then $Y." Internal analysis informs the decision; the result is a discrete number; we explain it when it ships. | |
| 69 | - | ||
| 70 | - | ### Inputs to a price-change decision | |
| 71 | - | ||
| 72 | - | A price change is evaluated when *any* of these is true: | |
| 73 | - | - The founding cohort cap is reached (forces standard-rate review). | |
| 74 | - | - Reserves reach $R_\text{cap}$ for the first time (forces surplus-disposition review — see `reserve_policy.md`). | |
| 75 | - | - Trailing-12-month measured cost-to-deliver per creator falls below or rises above an internal threshold. | |
| 76 | - | - A structural shock occurs (vendor pricing change, regulatory cost, etc.). | |
| 77 | - | - A scheduled annual review (every January). | |
| 78 | - | ||
| 79 | - | ### What the analysis must include | |
| 80 | - | ||
| 81 | - | Documented in `sops/pricing-change-decision.md`: | |
| 82 | - | - Current cost-to-deliver per tier (marginal infra + amortized platform overhead, *not* including T1/T2/T3 tickets). | |
| 83 | - | - Reserve health relative to $R_\text{cap}$. | |
| 84 | - | - Founding-cohort vs standard-rate signup velocity comparison (the elasticity signal — see §5). | |
| 85 | - | - Forward 12-month runway model under the proposed price. | |
| 86 | - | - Comms plan: who hears what, when, with what reasoning. | |
| 87 | - | ||
| 88 | - | ### What is committed in writing publicly | |
| 89 | - | ||
| 90 | - | In `guarantees.md` and `pricing.md` (public): | |
| 91 | - | - Prices will never rise except under the conditions listed in `guarantees.md`. | |
| 92 | - | - 90 days notice on any change. | |
| 93 | - | - 12-month grandfathering for any creator on a higher rate. | |
| 94 | - | - When prices change, the reasoning is published in the same notice. | |
| 95 | - | ||
| 96 | - | No public formula. No public dashboard. No public trigger thresholds. | |
| 97 | - | ||
| 98 | - | --- | |
| 99 | - | ||
| 100 | - | ## 5. What gets measured | |
| 101 | - | ||
| 102 | - | For the founding-cohort strategy to be informative rather than just generous, the comparison data has to be captured cleanly from day one. | |
| 103 | - | ||
| 104 | - | ### Cohort metrics (see `assumptions.md` A28) | |
| 105 | - | ||
| 106 | - | | Metric | Why | Cadence | | |
| 107 | - | |---|---|---| | |
| 108 | - | | Founding-cohort signups / month | Demand at founding rate | Monthly | | |
| 109 | - | | Founding-cohort signups by tier | Tier-mix at lower price | Monthly | | |
| 110 | - | | Days to cohort cap | Velocity benchmark | Once | | |
| 111 | - | | Standard-rate signups / month (after cap) | Demand at standard rate | Monthly | | |
| 112 | - | | Standard-rate signups by tier | Tier-mix at standard price | Monthly | | |
| 113 | - | | Ratio of post-cap monthly signup rate to pre-cap rate | First-order elasticity signal | Quarterly after cap | | |
| 114 | - | | Churn rate, founding cohort vs standard | Whether cheaper-acquired creators stay | Quarterly | | |
| 115 | - | | Revenue per founding creator over lifetime | LTV by cohort | Annually | | |
| 116 | - | ||
| 117 | - | ### Cost-to-deliver metrics (see `assumptions.md` A26) | |
| 118 | - | ||
| 119 | - | | Metric | Why | Cadence | | |
| 120 | - | |---|---|---| | |
| 121 | - | | Total platform-overhead time / month | Denominator of cost amortization | Weekly time log | | |
| 122 | - | | Platform-overhead time / active creator | The number that drives price-floor analysis | Monthly | | |
| 123 | - | | Per-tier marginal infra cost (storage + egress + chargeback) | Lower bound on per-tier price | Monthly | | |
| 124 | - | | T1/T2/T3 ticket rates | Quality signals (not pricing inputs) | Monthly | | |
| 125 | - | ||
| 126 | - | The cost-to-deliver number does **not** include T1 (bug-driven), T2 (UX-error-driven), or T3 (abuse) ticket time as a per-creator cost. T1 and T2 are quality failures that should drive dev/design fixes, not pricing. T3 is bounded by structural defenses. See `assumptions.md` A27. | |
| 127 | - | ||
| 128 | - | --- | |
| 129 | - | ||
| 130 | - | ## 6. Public-facing version | |
| 131 | - | ||
| 132 | - | The creator-facing pricing page is a separate, shorter doc. It contains: | |
| 133 | - | ||
| 134 | - | - The four tier prices and what each includes. | |
| 135 | - | - One short paragraph on how we think about cost (high level, no formulas). | |
| 136 | - | - The commitments from `guarantees.md` (no surprise raises, 90 days notice, grandfathering). | |
| 137 | - | - A note on earn-back credit (when implemented, by 2027-01-01 per memory). | |
| 138 | - | ||
| 139 | - | It does **not** contain: | |
| 140 | - | - Reserve targets or cap values. | |
| 141 | - | - Margin or break-even analysis. | |
| 142 | - | - The cost-to-deliver methodology. | |
| 143 | - | - The founding-cohort signup count or cap. | |
| 144 | - | - Anything about elasticity, cohort tracking, or internal pricing-change triggers. | |
| 145 | - | ||
| 146 | - | Those live here, internally. | |
| 147 | - | ||
| 148 | - | --- | |
| 149 | - | ||
| 150 | - | ## 7. Open decisions (for review before launch) | |
| 151 | - | ||
| 152 | - | These are not yet committed. The current doc reflects the current proposal; each needs explicit approval. | |
| 153 | - | ||
| 154 | - | 1. **Founding cohort cap size.** Proposed 500 / 12 months. Alternatives: 1000, no number cap (time-only), no time cap (number-only). | |
| 155 | - | 2. **Founding rate exactly at 50% of standard?** Or different ratios per tier (e.g., Basic at 50%, Everything at 60% because streaming costs scale)? | |
| 156 | - | 3. **Standard-rate values after cohort closes.** Currently provisional at $10/$20/$30/$60. May reset to $8/$15/$25/$50 or other; decision deferred until cohort data exists. | |
| 157 | - | 4. **Founding-rate price lock duration.** Lifetime-of-subscription is current proposal. Alternatives: 5 years, 10 years, cohort-window only. | |
| 158 | - | 5. **Tier-mobility behavior on founding-rate creators upgrading mid-lifetime.** Stay on founding ratios? Snap to standard for the new tier? Pro-rated middle ground? | |
| 159 | - | 6. **Founding-cohort marketing.** Frame founding rate as "structural early-supporter rate" (preferred) or "discount" (rejected per dark-patterns discussion). Confirm. | |
| 160 | - | ||
| 161 | - | --- | |
| 162 | - | ||
| 163 | - | ## 8. References | |
| 164 | - | ||
| 165 | - | - `reserve_policy.md` — reserve cap, surplus disposition, drawdown triggers | |
| 166 | - | - `assumptions.md` — A26 platform-overhead time; A27 ticket categorization; A28 cohort metrics | |
| 167 | - | - `stripe_fees.md` — fee formula propagated everywhere | |
| 168 | - | - `tier_mix.md` — assumed and measured tier mix | |
| 169 | - | - `guarantees.md` (public) — price-change commitments | |
| 170 | - | - `sops/pricing-change-decision.md` — decision protocol for any price change |
| @@ -1,485 +0,0 @@ | |||
| 1 | - | # Business Docs Remediation Plan | |
| 2 | - | ||
| 3 | - | Sourced from the 2026-05-16 audit across four clusters (infra/economics, SyncKit, legal/regulatory, support/ops/projections) plus subsequent decisions on pricing framework, reserve policy, and ticket categorization (see `pricing.md`, `reserve_policy.md`). | |
| 4 | - | ||
| 5 | - | Phases are ordered to maximize early ripple-correction: fix the formulas and reference values first, then propagate. | |
| 6 | - | ||
| 7 | - | Files referenced live under: | |
| 8 | - | - `MNW/server/docs/internal/business/` (internal business) | |
| 9 | - | - `MNW/server/docs/internal/strategy/` (internal strategy) | |
| 10 | - | - `MNW/server/site-docs/public/{about,tech,legal,support}/` (public) | |
| 11 | - | - `MNW/server/docs/pitches/` (pitches) | |
| 12 | - | ||
| 13 | - | ## Framework decisions (anchor for all phases below) | |
| 14 | - | ||
| 15 | - | These decisions, made during the 2026-05-16 audit follow-up, supersede earlier docs where they conflict: | |
| 16 | - | ||
| 17 | - | 1. **Pricing model is cost-plus with bounded reserves**, not value-extraction. See `pricing.md` and `reserve_policy.md`. Public-facing prices are clean dollar amounts; the analysis behind them is internal. | |
| 18 | - | 2. **Launch pricing is two-rate**: founding-creator rate (50% of standard) for the first 500 creators or 12 months, locked for lifetime of subscription; standard rate for new signups after the cohort closes. Standard rate is provisional until cohort data exists. | |
| 19 | - | 3. **Support tickets are categorized T1 (bug-driven) / T2 (UX-error-driven) / T3 (abuse).** T1 belongs in dev queue (would fix anyway); T2 belongs in design queue (a quality failure, not COGS); T3 is bounded by structural defenses. **None goes into per-creator pricing math.** | |
| 20 | - | 4. **"Per-creator ops cost" is the wrong unit.** The right unit is *platform-overhead time amortized across active creators* — which falls as N grows. See `assumptions.md` A26. | |
| 21 | - | 5. **MNW uses Stripe Connect Standard** for creator subscriptions ($0 platform fees). The `$2/account + 0.25%/payout` line that appears in legacy cost models is wrong for creator-fan flow. (Express may apply to SyncKit B2B if/when used.) | |
| 22 | - | 6. **No public dashboards, no public formulas, no public trigger thresholds.** The cost-to-serve analysis is internal; what creators see is prices and the `guarantees.md` commitments. | |
| 23 | - | ||
| 24 | - | --- | |
| 25 | - | ||
| 26 | - | ## Phase 0 — Reference artifacts (build first; everything cites these) | |
| 27 | - | ||
| 28 | - | Goal: create canonical sources so subsequent fixes are one-liners pointing at a single number/formula. | |
| 29 | - | ||
| 30 | - | | # | Artifact | Location | Contents | | |
| 31 | - | |---|---|---|---| | |
| 32 | - | | 0.1 | Stripe fee reference | new: `internal/business/stripe_fees.md` | Formula `fee = 0.029·amount + 0.30` (US standard); Connect Standard ($0 platform); Connect Express ($2/active acct + 0.25% payout + $0.25/payout); dispute fee $15 once at dispute creation; Instant Payouts 1% min $0.50. Cite stripe.com/pricing. Worked examples on $1, $8, $10, $20, $30, $60. | | |
| 33 | - | | 0.2 | Current cost ledger (dated) | update: `internal/business/expenses.md` | Add `As-of: YYYY-MM-DD` header. Itemize every invoice line with invoice ID. Add Apple Developer $99/yr line. Add CO LLC annual report ~$10/yr line. Add domain renewals line with per-domain prices. Total: actual monthly burn. | | |
| 34 | - | | 0.3 | Hetzner SKU/price reference | new: `internal/business/hetzner_prices.md` | CCX13 €13.10, CCX23 €30, CPX11 €3.85, CPX31 €15, CX22 €4.59, Object Storage €5.99/TB, Volume €0.044/GB, IPv4 €0.60, LB €5.39, egress €1/TB overage (1TB/server included). Date stamp. | | |
| 35 | - | | 0.4 | Vendor pricing reference | new: `internal/business/vendor_prices.md` | Postmark plan ladder; Cloudflare free vs Pro $25; Fastmail per-mailbox; AWS S3/MediaConvert for comparisons; AWS Connect equivalents. | | |
| 36 | - | | 0.5 | Tier-mix assumption | new: `internal/business/tier_mix.md` | Stated assumption (e.g., 40% Basic / 30% SF / 20% BF / 10% Everything → avg ARPU $24 at standard rates, $12 at founding rates). SQL proxy: `SELECT tier, rate_class, COUNT(*) FROM creator_subscriptions WHERE active GROUP BY tier, rate_class`. Updated monthly. | | |
| 37 | - | | 0.6 | Assumption-and-proxy table | new: `internal/business/assumptions.md` | Master table from audit. Every numeric assumption used anywhere in the docs, with SQL/metric proxy and review cadence. See appendix at end of this doc. | | |
| 38 | - | | 0.7 | Pricing framework | already drafted: `internal/business/pricing.md` | Founding rate / standard rate, cohort definition, grandfathering, price-change protocol. Open decisions listed at end of doc — review before launch. | | |
| 39 | - | | 0.8 | Reserve policy | already drafted: `internal/business/reserve_policy.md` | $R_\text{cap}$ formula and current value (~$62K), surplus disposition rule, drawdown triggers, personal-to-company transition. Open decisions at end. | | |
| 40 | - | ||
| 41 | - | --- | |
| 42 | - | ||
| 43 | - | ## Phase 1 — Mechanical math/arithmetic/version corrections | |
| 44 | - | ||
| 45 | - | Goal: every wrong arithmetic result and stale identifier becomes correct. No structural changes. | |
| 46 | - | ||
| 47 | - | ### 1.1 Stripe fee math (propagate from 0.1) | |
| 48 | - | ||
| 49 | - | | File | Edit | | |
| 50 | - | |---|---| | |
| 51 | - | | `internal/business/fan-plus.md:10` | "MNW keeps ~$2.70/month net" → **$2.47** (`$8 − $0.53 − $5`). Show formula inline. | | |
| 52 | - | | `internal/business/fan-plus.md:107` | Stripe row "-$0.28 (3.5%)" → **-$0.53 (2.9% + $0.30)**. | | |
| 53 | - | | `internal/business/fan-plus.md:116-118` | Revenue scale: 100/500/1000 → **$247 / $1,235 / $2,470**. | | |
| 54 | - | | `internal/business/financial_dashboard.md:80,83` | Same Fan+ correction; flow downstream tables. | | |
| 55 | - | | `internal/business/financial_dashboard.md:97` | "5% on $12/yr" → use BB's actual $8/yr: **$0.532 / $8 = 6.65%**. | | |
| 56 | - | | `internal/strategy/tech_costs.md:82` | Basic processing `$0.15-0.30` → **$0.59**. | | |
| 57 | - | | `internal/strategy/tech_costs.md:95` | Small Files processing `$0.30-0.50` → **$0.88**. | | |
| 58 | - | | `internal/strategy/tech_costs.md:108` | Big Files processing `$0.60-0.80` → **$1.17**. | | |
| 59 | - | | `internal/strategy/tech_costs.md:124` | Everything processing `$1.44-1.74` → **$2.04**. | | |
| 60 | - | | `internal/strategy/tech_costs.md` (all per-tier tables) | **Remove the "Stripe Connect $2.28/creator" line entirely.** MNW uses Stripe Connect *Standard*, which has $0 platform fees. The $2/account + 0.25%/payout + $0.25/payout is Express pricing and does not apply to creator subscriptions. (If SyncKit B2B uses Express later, it goes in `synckit_pricing.md`, not here.) | | |
| 61 | - | | `internal/business/synckit_pricing.md:24` | Hetzner egress `~$0.01/GB` → **~$0.0011/GB**. Recompute burst margin: ~67% → **~96%**. | | |
| 62 | - | | `internal/business/synckit_pricing.md:28` | Burst on AWS "drops to ~0%" → **negative** (egress $0.09/GB > burst $0.03/GB). | | |
| 63 | - | | `internal/business/synckit_pricing.md` (examples) | 10 GB @ 5x: $4.50 → **$3.00**. 50 GB @ 5x: $22.50 → **$15.00**. Re-verify all eight worked examples against `weight·storage + multiplier·storage·burst`. | | |
| 64 | - | | `internal/business/TODO_revenue_projections.md:54` | Conservative `~$150` → **$162** with shown math. | | |
| 65 | - | | `internal/business/TODO_revenue_projections.md:55` | Moderate `~$620` → **$545**. | | |
| 66 | - | | `internal/business/TODO_revenue_projections.md:56` | Optimistic `~$1,650` → **$1,471**. | | |
| 67 | - | | `internal/strategy/pitch.md:32` | Break-even `32 creators` → **28.6** at stated $24/$3, or restate the tier-mix that yields 32. | | |
| 68 | - | | `internal/business/chargeback_protection_fund.md:100` | Poisson "5+ … 1.8%" → **1.4%** (sum tail at λ=1.5). | | |
| 69 | - | | `internal/business/chargeback_protection_fund.md:20` | Drop "Fighting and losing adds another $15." Stripe dispute fee is charged once at dispute creation. | | |
| 70 | - | | `site-docs/public/about/how-we-work.md:47-57` | $1k/$10k/$50k Stripe lines: replace "~3%" with formula. State per-txn-count assumption (e.g., "100 fan transactions/mo on $1k = $59 in Stripe, not $30"). Recompute every cell. | | |
| 71 | - | ||
| 72 | - | ### 1.2 Stale identifiers | |
| 73 | - | ||
| 74 | - | | File | Edit | | |
| 75 | - | |---|---| | |
| 76 | - | | `pitches/synckit.html` (3 occurrences) | "v0.2.1" → **v0.3.1**. | | |
| 77 | - | | `internal/strategy/synckit_vps_separation.md:24` | "MNW server (Actix-Web)" → **Axum**. | | |
| 78 | - | | `internal/strategy/synckit_vps_separation.md:101` | "CX32 (4 vCPU 8GB) ~$15/mo" → **CPX31 €15/mo**. | | |
| 79 | - | | `internal/strategy/synckit_vps_separation.md:102` | "CX42 (8 vCPU 16GB) ~$30/mo" → **CCX23 €30/mo**. | | |
| 80 | - | | `internal/business/business_sustainability_audit.md:21` | "~247K LOC, ~5,200 tests" → **~88K LOC server, 1,935 tests** (or rerun `tokei` + `cargo test -- --list` and update with the run command shown). | | |
| 81 | - | | `internal/business/business_sustainability_audit.md:80,82,93,94,96` | All "Hetzner ~$15-30 / S3 ~$5-20 / Postmark ~$10-50 / total ~$600" → match `expenses.md` ledger (per 0.2). | | |
| 82 | - | | `internal/business/business_sustainability_audit.md:315` | Reference to `checkout/subscriptions.rs:74-79` → update to current Everything-block code path or remove. | | |
| 83 | - | | `internal/business/business_sustainability_audit.md:382` | Drop "Replace with Redis" suggestion (no Redis in stack). | | |
| 84 | - | | `internal/strategy/storage_cdn.md:33,35,58` | Hetzner Object Storage `€4.99` → **€5.99**; "additional storage €0.005/GB" → **€0.00599/GB (€5.99/TB)**. | | |
| 85 | - | ||
| 86 | - | ### 1.3 1099-K threshold (3 docs) | |
| 87 | - | ||
| 88 | - | Look up current TY2026 IRS threshold via irs.gov, then update: | |
| 89 | - | - `internal/strategy/pitch.md:137` | |
| 90 | - | - `internal/business/financial_dashboard.md:349` | |
| 91 | - | - `site-docs/public/legal/payments.md:109` (verify; may already point to Stripe link) | |
| 92 | - | ||
| 93 | - | If the threshold is still in legislative flux, link to the Stripe 1099-K explainer rather than naming a number. | |
| 94 | - | ||
| 95 | - | ### 1.4 State count for MTL (3 docs) | |
| 96 | - | ||
| 97 | - | Single canonical phrasing: **"49 states + DC; Montana exempts"** with `mtl_landscape.md` as source. | |
| 98 | - | - `internal/business/mtl.md:24` | |
| 99 | - | - `internal/business/payment-independence.md:42` | |
| 100 | - | - `internal/strategy/pitch.md` | |
| 101 | - | ||
| 102 | - | ### 1.5 Other small factual fixes | |
| 103 | - | ||
| 104 | - | | File:line | Edit | | |
| 105 | - | |---|---| | |
| 106 | - | | `internal/business/payment-independence.md:17` | "40+ countries" → **46+** (match `payments.md`). | | |
| 107 | - | | `internal/business/economics.md:223` | "Open source" → **source-available (PolyForm Noncommercial)**. | | |
| 108 | - | | `internal/business/economics.md:188` | "6-12 months runway" → **4.4 years** (from `financial_dashboard.md`). | | |
| 109 | - | | `internal/business/economics.md:165` | "CDN: pennies per GB" → **Cloudflare free egress; Hetzner egress €1/TB**. | | |
| 110 | - | | `site-docs/public/tech/infrastructure.md:44` | Astra "different provider" → **separate machine on personal hardware**. | | |
| 111 | - | | `pitches/synckit.html` comparison row | Firebase "Schema-agnostic: Yes" → **doc-store schema**. | | |
| 112 | - | | `internal/strategy/pitch.md:42` | DMCA "$500-1,000 including registration" → split: **$6 USCO agent fee + $500-1,000 attorney** (cite uscopyright.gov). | | |
| 113 | - | | `internal/strategy/pitch.md:46` | Trademark "$250-350/class" → cite uspto.gov TEAS Plus/Standard. | | |
| 114 | - | ||
| 115 | - | --- | |
| 116 | - | ||
| 117 | - | ## Phase 2 — Phantom removals | |
| 118 | - | ||
| 119 | - | Goal: every claim that names a feature/service/source that doesn't exist gets removed or labeled aspirational. | |
| 120 | - | ||
| 121 | - | ### 2.1 Phantom infrastructure line items | |
| 122 | - | ||
| 123 | - | | File:line | Action | | |
| 124 | - | |---|---| | |
| 125 | - | | `internal/strategy/tech_costs.md:18` | Remove "+ Redis" from CCX13 description. | | |
| 126 | - | | `internal/strategy/tech_costs.md:121-124` | Mark Everything-tier rows (Live infrastructure, VOD storage, CDN, Transcoding) as **"projected — feature not in production"**. Or move to new `projected_tech_costs.md`. | | |
| 127 | - | | `internal/strategy/tech_costs.md:148` | Remove "Tiered storage: old content moves to cheaper storage classes" (Hetzner has no tiers, not implemented). | | |
| 128 | - | | `internal/strategy/tech_costs.md:146,149` | Remove "Modern codecs reduce…" and "Geographic routing" (free CF, already covered). | | |
| 129 | - | | `internal/business/economics.md:166` | Remove "Transcoding: On-demand, no dedicated servers." Not built. | | |
| 130 | - | | `site-docs/public/about/economics.md:22` | Drop "cache" and "load balancer" from infra line. | | |
| 131 | - | | `site-docs/public/tech/infrastructure.md:87` | "Multiple servers behind load balancer (at scale)" → **"Single-server today; load balancer planned at scale"**. | | |
| 132 | - | | `site-docs/public/tech/infrastructure.md:79` | Remove "Workers for edge logic if needed" (not used). | | |
| 133 | - | | `site-docs/public/tech/infrastructure.md:103-110` | Remove "What We Don't Disclose" section (doc already names every vendor). | | |
| 134 | - | ||
| 135 | - | ### 2.2 Phantom statistics — delete (faster than sourcing) | |
| 136 | - | ||
| 137 | - | | File:line | Claim | | |
| 138 | - | |---|---| | |
| 139 | - | | `internal/strategy/pitch.md:175` | "312% better revenue retention, 89% more predictable income" | | |
| 140 | - | | `internal/strategy/synckit-plan.md:38` | "400% Firebase cost increase" | | |
| 141 | - | | `internal/strategy/synckit-plan.md:39` | "73% of developers experienced bill shock" | | |
| 142 | - | | `internal/strategy/synckit-plan.md:763` | "68% of SaaS companies reported overruns" | | |
| 143 | - | | `internal/strategy/pitch.md:169` | "140 million creators with 1k-10k audiences" | | |
| 144 | - | | `internal/strategy/synckit-plan.md:46` | "CloudKit limited storage (1GB free)" (wrong; Apple gives 5GB iCloud and CloudKit scales) | | |
| 145 | - | ||
| 146 | - | If you want any kept, replace with current cited number; otherwise delete. | |
| 147 | - | ||
| 148 | - | ### 2.3 Phantom statistics — source with date | |
| 149 | - | ||
| 150 | - | | File:line | Claim | Required citation | | |
| 151 | - | |---|---|---| | |
| 152 | - | | `internal/strategy/pitch.md:167` | Creator economy $250B → $480B by 2027 | Goldman Sachs 2023 Creator Economy report | | |
| 153 | - | | `internal/strategy/pitch.md:167` | "200M global / 162M US / 47% full-time" | Mixed (Linktree, Adobe, SignalFire) — cite per stat | | |
| 154 | - | | `internal/strategy/pitch.md:173` | Patreon 224K creators, $2B annual, 10% fee, 1.3 Trustpilot | Patreon press + Trustpilot snapshot (date the snapshot) | | |
| 155 | - | | `internal/strategy/pitch.md:173` | Substack 17K+ paying creators, $450M annual | Substack disclosed figures (date) | | |
| 156 | - | | `internal/strategy/pitch.md:173` | YouTube monetizes 2.6% of 115M channels | Source | | |
| 157 | - | | `internal/strategy/pitch.md:175` | Ghost 31% YoY migrations from Substack | Ghost blog post | | |
| 158 | - | | `internal/strategy/pitch.md:175` | Kajabi "60% arrive after outgrowing entry-level" | Kajabi report | | |
| 159 | - | | `site-docs/public/about/merchant-of-record.md:20` | "Platforms typically charge 10-30%" | Each platform's published fee | | |
| 160 | - | | `site-docs/public/about/merchant-of-record.md:46` | "well below 0.5% industry average" chargebacks | Stripe industry data or Chargebacks911 report | | |
| 161 | - | | `internal/business/chargeback_protection_fund.md:47` | "industry average ~0.5% for digital goods" | Same | | |
| 162 | - | | `internal/business/chargeback_protection_fund.md:154` | "Stripe, Shopify, Etsy, PayPal structure seller protection like this" | Each platform's seller-protection terms | | |
| 163 | - | ||
| 164 | - | If a citation cannot be found in one work session, delete the claim. | |
| 165 | - | ||
| 166 | - | ### 2.4 Phantom features described as fact | |
| 167 | - | ||
| 168 | - | | File:line | Action | | |
| 169 | - | |---|---| | |
| 170 | - | | `site-docs/public/about/how-we-work.md:133` | "Residency program training people without traditional credentials" → label **planned** like Content Archive item. | | |
| 171 | - | | `internal/business/partnerships.md:27` | "All partnerships are publicly disclosed" → either create `/partners` page or delete claim. | | |
| 172 | - | | `internal/business/partnerships.md:37` | "We plan to offer distribution to Spotify, Apple Music" → add to `roadmap.md` first, then link; otherwise remove. | | |
| 173 | - | | `site-docs/public/about/roadmap.md:87` | "most applications approved within 1 business day" → either measure (proxy: SQL) and commit to a number, or change to "we aim to." | | |
| 174 | - | | `site-docs/public/tech/infrastructure.md` (Stripe section) | "Exit: migrate to backup processor" → "Roadmap item (no backup integration yet)". | | |
| 175 | - | | `internal/business/payment-independence.md:48` | "If we negotiate volume discounts, those savings go to creators" → mechanism or delete. | | |
| 176 | - | | `internal/business/fan-plus.md:171` | "Prorated refund if Fan+ shut down" → SOP reference required (see Phase 4) or delete. | | |
| 177 | - | ||
| 178 | - | ### 2.5 Vague-filler deletions | |
| 179 | - | ||
| 180 | - | Each is non-load-bearing prose that the audit flagged for removal. Delete: | |
| 181 | - | ||
| 182 | - | | File:line | Phrase | | |
| 183 | - | |---|---| | |
| 184 | - | | `internal/business/economics.md:26` | "$100/month creator uses roughly the same infrastructure as $10,000/month" | | |
| 185 | - | | `internal/business/economics.md:152-157` | "No sales team / no marketing budget / no office space" (last is contradicted — coworking $332/mo) | | |
| 186 | - | | `internal/business/economics.md:166,175` | "S3 and equivalents are cheap at scale" / "500 happy creators … 50,000 also sustainable" | | |
| 187 | - | | `internal/business/economics.md:233` | "fewer creators = reduced costs (cloud scales down)" | | |
| 188 | - | | `internal/business/business_sustainability_audit.md:166-167` | "Each trust level reduces … 10-15 hours/week"; "single L3 resident raises ceiling from ~500 to ~1,500" | | |
| 189 | - | | `internal/business/business_sustainability_audit.md:280` | "70 hours/week at 500 creators" | | |
| 190 | - | | `internal/business/business_sustainability_audit.md:381` | "Single VPS handles 5,000 daily users" | | |
| 191 | - | | `internal/business/business_sustainability_audit.md:147` | "~$150K+ senior engineer" comparison | | |
| 192 | - | | `internal/strategy/tech_costs.md:83,96,109,125` | "Infrastructure share $0.40-0.80" (no derivation in any tier row — replace with formula in Phase 4) | | |
| 193 | - | | `internal/strategy/tech_costs.md:167-169` | "Data analytics infrastructure / content moderation at scale / investor relations" don't-have items (self-evident) | | |
| 194 | - | | `internal/strategy/tech_costs.md:215` | "These projections assume current cost structures" (acceptable disclaimer; can keep) — actually keep | | |
| 195 | - | | `internal/strategy/storage_cdn.md:17,81,90` | "Median compressed size ~300-600 MB"; "Cloudflare runs one of the largest transit networks"; "genuinely free at MNW's growth horizon" | | |
| 196 | - | | `internal/business/synckit_pricing.md:7-11` | Principles 1-5 prose ("Easy to understand", "Friendly to power users", "Always predictable") — compress to one-line principle list | | |
| 197 | - | | `internal/business/app_sync_pricing.md:33,40,73-74` | "14 tables vs 7" / "GO is a more complex app" / "consistent with MNW's transparency principles" | | |
| 198 | - | | `internal/strategy/synckit-plan.md:117-166,188-205,468-515` | Archived `<details>Superseded</details>` blocks — **delete outright**, don't collapse | | |
| 199 | - | | `internal/strategy/synckit-plan.md:331-335,758-769` | Marketing taglines; "Why This Will Work" 10-point list | | |
| 200 | - | | `internal/strategy/synckit-plan.md:170-172` | "Realtime +$10 / domain +$5 / priority $50" add-ons (contradicts canonical TBD) | | |
| 201 | - | | `internal/strategy/synckit-plan.md:498-513,723-753` | Growth projections without model; risk/mitigation prose without measurable triggers | | |
| 202 | - | | `internal/strategy/synckit-plan.md:809-810` | "developers will pay $20/month" thesis (contradicts canonical model) | | |
| 203 | - | | `pitches/synckit.html:527,826` | "Ship it in an afternoon"; "Typical integration: under a day" | | |
| 204 | - | | `pitches/synckit.html:919-924` | "Time to integrate: Hours/Days/Weeks" comparison row | | |
| 205 | - | | `internal/business/partnerships.md:31` | "Every external dependency is a cost we pass to creators" | | |
| 206 | - | | `internal/business/partnership-targets.md:17,65` | Ghost "Large creator audience"; Obsidian "high overlap to ours" | | |
| 207 | - | | `internal/business/partnership-targets.md:278-294` | Priority order without stated rubric — either state the rubric or remove the ranking | | |
| 208 | - | | `internal/business/compliance.md:71,77-78` | "We don't cut corners on compliance" / "Your data is handled properly / payments are secure" | | |
| 209 | - | | `internal/business/mtl.md:31` | "Every other country has its own framework. No shortcut." | | |
| 210 | - | | `internal/business/chargeback_protection_fund.md:24,62,110,111` | "fits the MNW narrative"; "2.5x recommended"; "minimum 50 creators"; "3-month buildup" — convert to assumption-with-proxy in Phase 4 or remove | | |
| 211 | - | | `site-docs/public/about/economics.md:50,102,112` | "Each new team member should deliver a clear improvement"; "Ride-sharing companies burned billions"; "Hosting costs trend down" | | |
| 212 | - | | `site-docs/public/about/how-we-work.md:127` | "Founder and company both carry a zero balance" (redundant with no-debt) | | |
| 213 | - | | `site-docs/public/about/guarantees.md:87,131` | "Personal savings sufficient to cover years" → state 4.4y from financial_dashboard; "We collect only what we need to operate" → link to schema doc | | |
| 214 | - | | `site-docs/public/about/guarantees.md:37` | "Cancellation always as easy or easier than signing up" → replace with measurable ("single click in account settings", code ref) | | |
| 215 | - | | `site-docs/public/support/faq.md:172` | "exceptions for content that threatens the platform's existence" → enumerate exceptions (legal process, NCMEC, etc.) | | |
| 216 | - | ||
| 217 | - | ### 2.6 Synckit pitch — pricing contradiction | |
| 218 | - | ||
| 219 | - | `pitches/synckit.html:929-954` shows the **MNW creator tiers ($10/$20/$30/$60)** as SyncKit B2B pricing. This contradicts `synckit_pricing.md`'s Simple/Builder per-GB model. Two valid resolutions: | |
| 220 | - | ||
| 221 | - | - **Option A**: Pitch is for creator-facing sync (end-users on MNW). Make this explicit and don't call it B2B SyncKit pricing. | |
| 222 | - | - **Option B**: Pitch is for B2B SyncKit. Replace pricing block with the Simple/Builder model from `synckit_pricing.md`. | |
| 223 | - | ||
| 224 | - | Decide which and align. | |
| 225 | - | ||
| 226 | - | --- | |
| 227 | - | ||
| 228 | - | ## Phase 3 — Restructure public pages + internal cost docs | |
| 229 | - | ||
| 230 | - | Goal: public pages contain clean dollar amounts and high-level commitments. All quantitative cost analysis stays internal. Internal docs are dated, sourced, and reconciled. | |
| 231 | - | ||
| 232 | - | ### 3.1 `site-docs/public/about/economics.md` rewrite — simplified | |
| 233 | - | ||
| 234 | - | This page should **not** contain margin tables, break-even formulas, fixed-cost line items, or per-tier cost-to-serve numbers. Those are internal. Strip them out. | |
| 235 | - | ||
| 236 | - | Replace the page with a short narrative: | |
| 237 | - | ||
| 238 | - | 1. **What you pay.** Tier prices, founding rate vs standard rate (per `pricing.md`). | |
| 239 | - | 2. **What it covers, at a high level.** Three buckets, no dollars: cost to deliver (infra, payment processing), platform overhead (development, ops, legal, reserves), commitment to return surplus (earn-back credit by 2027-01-01). | |
| 240 | - | 3. **What we commit to.** Cross-reference `guarantees.md`: no surprise raises, 90 days notice, grandfathering. Direction is downward when our cost structure permits. | |
| 241 | - | 4. **What we won't do.** Percentage cuts. Per-transaction skim. Surge pricing. Plan-gated features moving between tiers without notice. | |
| 242 | - | ||
| 243 | - | Date-stamp at top. No dollar amounts other than tier prices. No tables. | |
| 244 | - | ||
| 245 | - | Delete from this page: the "roughly $600/month" prose, the per-tier cost ranges, the break-even creator count, the "500 creators costs roughly the same as 100" claim. These either move to internal docs or get deleted. | |
| 246 | - | ||
| 247 | - | ### 3.2 `site-docs/public/about/pricing.md` (NEW — public version) | |
| 248 | - | ||
| 249 | - | Short page derived from internal `pricing.md`. Contains: | |
| 250 | - | - Four tier prices (founding rate now, standard rate post-cohort). | |
| 251 | - | - One sentence per tier on what's included. | |
| 252 | - | - One paragraph on how we think about cost (no formulas). | |
| 253 | - | - Link to `guarantees.md` for change commitments. | |
| 254 | - | ||
| 255 | - | Explicitly does **not** contain: cohort cap value, founding-cohort signup count, reserve targets, cost-to-serve methodology, elasticity tracking, anything about T1/T2/T3 categorization. | |
| 256 | - | ||
| 257 | - | ### 3.3 `internal/strategy/tech_costs.md` restructure | |
| 258 | - | ||
| 259 | - | Internal doc — full rigor allowed. Add at top: **assumptions block** listing every per-tier storage/CDN/overhead assumption with its proxy ID from `assumptions.md`. Then the per-tier tables become "computed from those assumptions" rather than "estimated." | |
| 260 | - | ||
| 261 | - | For Everything tier, split into: | |
| 262 | - | - **Currently active** (storage, processing, share of fixed cost) — measured | |
| 263 | - | - **Projected when streaming ships** (live infra, VOD, transcoding) — explicitly labeled future | |
| 264 | - | ||
| 265 | - | Add bandwidth-overage line per tier with the Hetzner €1/TB rate. State the included 1TB/server threshold. | |
| 266 | - | ||
| 267 | - | **Remove the Stripe Connect Express line from per-tier creator-subscription rows** (see Phase 1.1). Creator subscriptions go through Stripe Connect Standard ($0 platform fee). The Stripe processing fee on the *creator's tier sub* uses the 2.9% + $0.30 formula and is the only Stripe cost in the per-creator math. | |
| 268 | - | ||
| 269 | - | Add a separate section for *fan-to-creator transaction flow*: under Standard, MNW pays $0 in Connect fees regardless of payout volume. This is the structural cost win and should be explicit. | |
| 270 | - | ||
| 271 | - | ### 3.4 Internal `economics.md` reconciliation | |
| 272 | - | ||
| 273 | - | Currently disagrees with `tech_costs.md` and `financial_dashboard.md` on per-creator costs and break-even count. Pick one canonical doc (recommend `economics.md` for principles + `tech_costs.md` for numbers). Make the other two link to it. | |
| 274 | - | ||
| 275 | - | Resolve the "moderate adoption ~$600/mo" claim — at the stated user counts the math doesn't clear actual $580 (per `expenses.md`). Either change adoption assumption or restate. | |
| 276 | - | ||
| 277 | - | Internal `economics.md` should also be updated to reflect the cost-plus-with-bounded-reserves framework (cross-ref `pricing.md` and `reserve_policy.md`), not the old "we have healthy margins" framing. | |
| 278 | - | ||
| 279 | - | ### 3.5 What does NOT change | |
| 280 | - | ||
| 281 | - | The following stay internal-only and are *not* candidates for public publication: | |
| 282 | - | ||
| 283 | - | - Margin tables per tier | |
| 284 | - | - Reserve target ($R_\text{cap}$) and current balance | |
| 285 | - | - Surplus disposition split (20/80 reserve/earn-back) | |
| 286 | - | - Cohort signup velocity | |
| 287 | - | - Cost-to-serve methodology | |
| 288 | - | - T1/T2/T3 ticket rates | |
| 289 | - | - Platform-overhead time per creator | |
| 290 | - | ||
| 291 | - | Phase 6 includes a grep step to confirm none of these leak into public-facing docs. | |
| 292 | - | ||
| 293 | - | --- | |
| 294 | - | ||
| 295 | - | ## Phase 4 — Convert remaining assumptions to proxied form | |
| 296 | - | ||
| 297 | - | Goal: every retained quantitative assumption has a SQL query or metric pointer, and a review cadence. | |
| 298 | - | ||
| 299 | - | Build `internal/business/assumptions.md` with this skeleton (audit master list reproduced in appendix below). Each row: | |
| 300 | - | ||
| 301 | - | ``` | |
| 302 | - | | ID | Assumption | Current value | Proxy (SQL / metric) | Cadence | Last verified | | |
| 303 | - | ``` | |
| 304 | - | ||
| 305 | - | Then everywhere a doc says "we assume X = Y," replace with `(assumed: see assumptions.md#ID-N)`. | |
| 306 | - | ||
| 307 | - | Specific assumptions that need promotion from vague to proxied: | |
| 308 | - | ||
| 309 | - | | Where it currently lives | Assumption | Proxy | | |
| 310 | - | |---|---|---| | |
| 311 | - | | `chargeback_protection_fund.md:43` | Avg fan txn = $15 | Median `items.price_cents` quarterly | | |
| 312 | - | | `chargeback_protection_fund.md:44` | Chargeback rate = 0.15% | `disputes/charges` quarterly, recalibrate at N≥1000 | | |
| 313 | - | | `chargeback_protection_fund.md:62` | Reserve multiplier 2.5× | Tie to Poisson upper-bound at 95th pctile at participant count N | | |
| 314 | - | | `chargeback_protection_fund.md:110` | Min 50 participating creators | Variance ratio threshold | | |
| 315 | - | | `chargeback_protection_fund.md:111` | 3-month buildup | Months to reach IBNR buffer at expected GMV | | |
| 316 | - | | `chargeback_protection_fund.md:119` | Per-creator caps by tier | Cap = 2× expected at chargeback-rate ceiling | | |
| 317 | - | | `chargeback_protection_fund.md:130` | Experience rating 0.5x/1.0x/1.5x | Revisit at ≥6mo data | | |
| 318 | - | | `business_sustainability_audit.md` | DB pool 25 → ~200 users | Stress test result + live `pg_stat_activity` p95 | | |
| 319 | - | | `business_sustainability_audit.md` | Founder workload 70h/wk at 500 creators | Weekly time log by category | | |
| 320 | - | | `business_sustainability_audit.md` | "Trust level reduces 10-15 hrs/wk" | Same time log | | |
| 321 | - | | `mtl_landscape.md:139-145` | GMV thresholds for compliance decisions | Compliance cost / revenue ratio | | |
| 322 | - | | `pitch.md:28,30` | Avg variable cost $3/creator | Fixed monthly Hetzner-attributed cost / active creators | | |
| 323 | - | | `synckit_pricing.md` | 5× default burst multiplier | `SUM(bytes_transferred)/SUM(bytes_stored)` per app per month | | |
| 324 | - | | `app_sync_pricing.md` | BB ~1 MB/user, GO 1-5 MB/user, AF tier-dependent | Per-app `AVG(blob_size)` query | | |
| 325 | - | | `TODO_revenue_projections.md` | "GO is highest-WTP" | Post-launch ARPU per app | | |
| 326 | - | | `TODO_revenue_projections.md` | Conservative/Moderate/Optimistic timeframes | Monthly Stripe-subscription growth rate per app | | |
| 327 | - | | Multiple | Tier mix → avg ARPU $24 | `tier_mix.md` SQL | | |
| 328 | - | | Multiple | Cache-hit ratio (drives egress ≈ $0) | Cloudflare Analytics monthly cache-hit % | | |
| 329 | - | | `pricing.md` | Platform-overhead time per active creator (not "support cost per creator") | Weekly time log → monthly aggregate ÷ active creator count | | |
| 330 | - | | `pricing.md` | T1/T2/T3 ticket rates (quality signals, NOT pricing inputs) | Tag every ticket at intake; monthly count by tag | | |
| 331 | - | | `reserve_policy.md` | $R_\text{cap}$ formula and current value | Recompute when $F$ shifts >10% | | |
| 332 | - | | `pricing.md` | Founding-cohort vs standard-rate signup velocity ratio | Monthly signup count by rate class, post-cohort-close | | |
| 333 | - | | `reserve_policy.md` | Reserve balance vs $R_\text{cap}$ | Monthly bank balance check | | |
| 334 | - | ||
| 335 | - | --- | |
| 336 | - | ||
| 337 | - | ## Phase 5 — Legal citations + SOP docs for soft guarantees | |
| 338 | - | ||
| 339 | - | Goal: every legal/regulatory claim has a primary-source URL; every "soft guarantee" links to a written SOP or gets softened. | |
| 340 | - | ||
| 341 | - | ### 5.1 Legal claim citations | |
| 342 | - | ||
| 343 | - | | File | Claim | Required citation | | |
| 344 | - | |---|---|---| | |
| 345 | - | | `compliance.md` | DMCA safe harbor | DMCA agent registration receipt (USCO) in `_private/`, link from doc | | |
| 346 | - | | `compliance.md`, `mtl.md` | MNW is not a money transmitter | CRS 11-110 (Colorado MTL Act) + Stripe Connect Standard MOR docs; flag "needs lawyer sign-off" | | |
| 347 | - | | `chargeback_protection_fund.md:147` | "$100K min capital for CO captive" | CRS 10-6 (verify actual minimum — likely $500K for pure captives); needs lawyer | | |
| 348 | - | | `mtl_landscape.md:40-44` | Per-state MTL fees | Each state regulator fee schedule URL (NY DFS, CA DFPI, TX DOB, PA DOB, CO DORA) | | |
| 349 | - | | `mtl_landscape.md:48` | Cheapest-state fees | Each state fee schedule | | |
| 350 | - | | `mtl_landscape.md:58-61` | Surety bond ranges | State statutes | | |
| 351 | - | | `mtl_landscape.md:102,107,116` | BaaS / Tipalti / EU PI costs | Unit/Treasury Prime/Payoneer/Tipalti pricing pages | | |
| 352 | - | | `chargeback_protection_fund.md:47,52` | Visa VAMP 1.5%, Mastercard ECP | Visa Acquirer Risk Standards + Mastercard ECP page | | |
| 353 | - | | `chargeback_protection_fund.md:113` | 120-day IBNR | Visa Core Rules + Mastercard Chargeback Guide | | |
| 354 | - | | `merchant-of-record.md` | Stripe Tax "50+ countries" | stripe.com/tax | | |
| 355 | - | | `legal/payments.md:49` | Payout schedule + 1% instant fee | stripe.com/docs/payouts | | |
| 356 | - | | Compliance/GDPR/CCPA enumerations | Each right | Code path (export endpoint, deletion handler) | | |
| 357 | - | ||
| 358 | - | ### 5.2 Pitch.md legal cost estimates — get real quotes | |
| 359 | - | ||
| 360 | - | Each line needs either named-attorney quote or "estimated, pre-quote" label: | |
| 361 | - | - ToS / Privacy / Creator Agreement ($3-8K) | |
| 362 | - | - Payment Compliance consultation ($2-5K) | |
| 363 | - | - Penetration test ($2-5K) | |
| 364 | - | - DMCA work (split USCO fee + attorney) | |
| 365 | - | ||
| 366 | - | Deliverable: 2+ quotes per line item, or label the doc accordingly. | |
| 367 | - | ||
| 368 | - | ### 5.3 Soft guarantee → SOP docs | |
| 369 | - | ||
| 370 | - | Create `internal/business/sops/` with one short doc per guarantee: | |
| 371 | - | ||
| 372 | - | | SOP | Source guarantee | Contents | | |
| 373 | - | |---|---|---| | |
| 374 | - | | `sops/shutdown-notice.md` | 90-day shutdown notice | Trigger conditions, notification channels, export-window extension, refund handling | | |
| 375 | - | | `sops/price-change-notice.md` | 90-day price notice + 12mo grandfathering | Notification template, Stripe plan-migration steps, grandfathering enforcement (price IDs vs subscription state) | | |
| 376 | - | | `sops/fan-plus-shutdown.md` | Prorated Fan+ refund | Stripe refund API path, credit-balance handling | | |
| 377 | - | | `sops/dispute-resolution.md` | Moderation appeals "different reviewer" | Workflow once second person is hired; until then, label appeals as planned | | |
| 378 | - | | `sops/data-export-sla.md` | "Export within minutes" | Code path + p95 measurement; document the actual limit | | |
| 379 | - | | `sops/wal-archive.md` | "5-minute data loss" | PostgreSQL `archive_timeout` config; cite postgresql.conf | | |
| 380 | - | | `sops/backup-recovery.md` | Daily backups, 30-day retention, offsite replica | Cron schedule, verification cadence, RTO/RPO | | |
| 381 | - | | `sops/pricing-change-decision.md` | Internal — `pricing.md` §4 | Decision protocol: required analysis inputs (cost-to-deliver, reserve health, cohort signup velocity, runway model), comms plan template, founder approval log | | |
| 382 | - | | `sops/reserve-management.md` | Internal — `reserve_policy.md` | Reserve balance check cadence, $R_\text{cap}$ recompute trigger, drawdown approval flow, ledger entry format | | |
| 383 | - | | `sops/ticket-categorization.md` | Internal — A27 | T1/T2/T3 tagging rules at intake, edge cases, monthly review of T1/T2 patterns feeding into bug-fix queue and UX roadmap | | |
| 384 | - | | `sops/founding-cohort-tracking.md` | Internal — `pricing.md` §2 | How the 500-creator / 12-month cap is tracked, who is notified at 80% and 100%, what happens at cap (standard-rate Stripe price IDs activate) | | |
| 385 | - | ||
| 386 | - | Each guarantee in `guarantees.md`, `how-we-work.md`, `faq.md` gets `(SOP: ../../internal/business/sops/X.md)` appended. | |
| 387 | - | ||
| 388 | - | ### 5.4 GDPR/CCPA right-to-code mapping | |
| 389 | - | ||
| 390 | - | In `compliance.md`, replace the bare enumeration of rights with a mapping table: | |
| 391 | - | ||
| 392 | - | | Right | Code path | Verification | | |
| 393 | - | |---|---|---| | |
| 394 | - | | Right to access (GDPR 15) | `routes/export.rs:...` | Manual test quarterly | | |
| 395 | - | | Right to erasure (GDPR 17) | `routes/account_lifecycle.rs:...` | Same | | |
| 396 | - | | ... | ... | ... | | |
| 397 | - | ||
| 398 | - | --- | |
| 399 | - | ||
| 400 | - | ## Phase 6 — Consistency sweep + commit | |
| 401 | - | ||
| 402 | - | Goal: final pass to ensure every external doc cites the reference artifacts from Phase 0, and no internal-only material leaks into public docs. | |
| 403 | - | ||
| 404 | - | ### 6.1 Internal artifact citations | |
| 405 | - | ||
| 406 | - | - Run a grep for the canonical sources and verify each appears where expected: `stripe_fees.md`, `hetzner_prices.md`, `assumptions.md`, `tier_mix.md`, `expenses.md`, `pricing.md`, `reserve_policy.md`. | |
| 407 | - | - Verify no two docs disagree on: state count, total monthly burn, SDK version, server framework, per-tier Stripe fee, Hetzner SKU prices, dispute fee, instant-payout fee. | |
| 408 | - | - Verify Stripe Connect Standard ($0 platform fees) is the canonical statement everywhere creator subscriptions are discussed. No remnants of the Express $2/account line in creator-cost contexts. | |
| 409 | - | ||
| 410 | - | ### 6.2 Public/internal boundary check | |
| 411 | - | ||
| 412 | - | Grep public docs (`site-docs/public/**`) for terms that should *not* appear there: | |
| 413 | - | ||
| 414 | - | - `$R_\text{cap}`, `reserve cap`, `61,960`, `62,000`, or any specific reserve figure | |
| 415 | - | - `founding cohort cap`, `500 creators`, `12-month cap` as numbers (the existence of founding rate is public; the cap value isn't) | |
| 416 | - | - Margin tables, break-even creator count, cost-to-serve dollar amounts per tier | |
| 417 | - | - `T1`, `T2`, `T3`, ticket categorization terms | |
| 418 | - | - `platform-overhead time`, `cost-to-deliver methodology` | |
| 419 | - | - Any internal SOP path under `internal/business/sops/` | |
| 420 | - | ||
| 421 | - | If any of these appears in public docs, move it internal. | |
| 422 | - | ||
| 423 | - | ### 6.3 Date stamps and commit | |
| 424 | - | ||
| 425 | - | - Date-stamp every cost figure (`As of YYYY-MM`). | |
| 426 | - | - Single commit per phase. Commit messages reference this remediation plan. | |
| 427 | - | ||
| 428 | - | --- | |
| 429 | - | ||
| 430 | - | ## Appendix — Master assumptions list (input to `assumptions.md`) | |
| 431 | - | ||
| 432 | - | Every numeric assumption surfaced by the audit, with proposed proxy. Build the table from this. | |
| 433 | - | ||
| 434 | - | | # | Assumption | Current | Proxy | Cadence | | |
| 435 | - | |---|---|---|---|---| | |
| 436 | - | | A1 | Avg storage / Basic creator | ~100 MB | `SELECT AVG(storage_used_bytes) FROM creator_subscriptions JOIN storage_usage ... WHERE tier='basic'` | monthly | | |
| 437 | - | | A2 | Avg storage / Small Files | ~2 GB | same, tier='small_files' | monthly | | |
| 438 | - | | A3 | Avg storage / Big Files | ~10 GB | same, tier='big_files' | monthly | | |
| 439 | - | | A4 | Tier mix (avg ARPU $24) | 40/30/20/10 | `SELECT tier, COUNT(*) FROM creator_subscriptions WHERE active GROUP BY tier` | monthly | | |
| 440 | - | | A5 | Avg variable cost / creator | $3 | (monthly Hetzner cost) / (active creators) | monthly | | |
| 441 | - | | A6 | Cloudflare cache-hit ratio | unmeasured | CF Analytics monthly cache-hit % | monthly | | |
| 442 | - | | A7 | Hetzner egress vs 1TB free/server | unmeasured | Hetzner invoice egress GB per server | monthly | | |
| 443 | - | | A8 | BB sync payload / user | ~1 MB | `AVG(SUM(payload_size)) GROUP BY user_id` app='bb' | monthly | | |
| 444 | - | | A9 | GO sync payload / user | 1-5 MB | same, app='goingson' | monthly | | |
| 445 | - | | A10 | AF blob bytes / user / tier | tier-dependent | same, app='af', grouped by tier | monthly | | |
| 446 | - | | A11 | SyncKit default burst multiplier | 5× | `SUM(bytes_transferred)/SUM(bytes_stored)` per app | monthly | | |
| 447 | - | | A12 | Chargeback rate | 0.15% | `disputes / charges` | quarterly | | |
| 448 | - | | A13 | Median item price | $15 | `PERCENTILE_CONT(0.5)` on item price | quarterly | | |
| 449 | - | | A14 | Creator-approval median latency | 1 business day | `PERCENTILE_CONT(0.5)` on `decided_at - submitted_at` | monthly | | |
| 450 | - | | A15 | Stripe fee per tier (Connect Express) | per `stripe_fees.md` | `AVG(stripe_fee_cents) GROUP BY tier` | monthly | | |
| 451 | - | | A16 | DB pool capacity → concurrent users | 25 → ~200 | live `pg_stat_activity` p95 + load test | quarterly | | |
| 452 | - | | A17 | Founder weekly hours | 40h baseline | time log by category | weekly | | |
| 453 | - | | A18 | Postmark volume vs free tier | <10K/mo | Postmark dashboard | monthly | | |
| 454 | - | | A19 | Fan+ redemption rate | unknown | `SUM(redeemed)/SUM(issued)` (when shipped) | monthly | | |
| 455 | - | | A20 | Fixed-cost step at 500/2000 creators | +$100 / +$400 | itemize trigger (e.g., add LB at 500) | one-time, then verify | | |
| 456 | - | | A21 | Reserve multiplier (chargeback fund) | 2.5× | Poisson 95th-pctile at participant count | quarterly | | |
| 457 | - | | A22 | Min participating creators (CB fund) | 50 | variance ratio threshold | one-time | | |
| 458 | - | | A23 | IBNR buffer | 120 days | longest observed dispute lag | quarterly | | |
| 459 | - | | A24 | Compliance-cost / revenue threshold for licensing | undefined | (annual compliance cost) / (annual GMV) | annually | | |
| 460 | - | | A25 | Build-size median (games, storage_cdn.md) | 300-600 MB | `PERCENTILE_CONT(0.5)` on game build sizes | one-time | | |
| 461 | - | | A26 | Platform-overhead time per active creator (not "support cost per creator") | unmeasured pre-launch | Weekly time log (5 buckets: feature dev / infra-deploy-monitor / business-legal-docs / direct creator interaction / other) ÷ active creator count | monthly aggregate | | |
| 462 | - | | A27 | T1 / T2 / T3 ticket rate | unmeasured pre-launch | Tag every support contact at intake; monthly count by tag. T1 → bug-fix queue. T2 → UX roadmap. T3 → abuse defense. Not used as a pricing input. | monthly | | |
| 463 | - | | A28 | $R_\text{cap}$ formula and current value | $61,960 (=$580·12 + $50K + $5K) | Recompute when $F$ (`expenses.md`) shifts >10% | event-driven + annual review | | |
| 464 | - | | A29 | Founding-cohort signup velocity vs standard-rate signup velocity | unmeasured (post-cohort-close) | `COUNT(*) FROM creator_subscriptions WHERE rate_class='founding'` vs `'standard'` per month; ratio | monthly after cohort closes | | |
| 465 | - | | A30 | Reserve balance vs $R_\text{cap}$ | $0 today | Monthly bank balance check, recorded in `reserve_policy.md` header | monthly | | |
| 466 | - | | A31 | Opportunistic fund ($R_\text{opp}$) | cap $10K, spend caps $2.5K/incident and $5K/yr | Bank sub-account or earmark + ledger | monthly balance + monthly rolling-spend + annual disclosure | | |
| 467 | - | ||
| 468 | - | --- | |
| 469 | - | ||
| 470 | - | ## Pre-launch decisions required | |
| 471 | - | ||
| 472 | - | Before launch, the open decisions in `pricing.md` §7 and `reserve_policy.md` §7 need explicit founder approval. The remediation phases below assume the current proposals (founding rate at 50%, 500-creator cap, 12 months, $R_\text{cap}$ = $62K, 20/80 surplus split). If any of these change, Phase 0.7 / 0.8 docs are updated and downstream references stay correct because they point to those docs rather than restating values. | |
| 473 | - | ||
| 474 | - | ## Suggested schedule | |
| 475 | - | ||
| 476 | - | Rough estimate based on the volume of edits. Adjust as you go. | |
| 477 | - | ||
| 478 | - | - **Day 0** (before starting): Review `pricing.md` §7 and `reserve_policy.md` §7 open decisions. Confirm or revise each. This anchors the rest of the work. | |
| 479 | - | - **Day 1**: Phase 0 (build reference artifacts; `pricing.md` and `reserve_policy.md` already drafted) + Phase 1 (mechanical fixes) | |
| 480 | - | - **Day 2**: Phase 2 (phantom removals) | |
| 481 | - | - **Day 3**: Phase 3 (restructure economics + tech_costs; new public `pricing.md`) | |
| 482 | - | - **Day 4**: Phase 4 (assumptions doc, including A26-A30) + Phase 5 SOPs | |
| 483 | - | - **Day 5**: Phase 5 legal citations + Phase 6 consistency sweep (especially the public/internal boundary grep in 6.2) | |
| 484 | - | ||
| 485 | - | Each phase is a coherent commit. Phase 1 is the highest-leverage (one Stripe-fee fix cascades through ~12 numbers); Phase 2 is the most cathartic (deleting the phantoms); Phase 6.2 is the most important for protecting the values commitment (internal-only material stays internal). |
| @@ -1,218 +0,0 @@ | |||
| 1 | - | # Reserve Policy | |
| 2 | - | ||
| 3 | - | **Status: draft — open decisions at the end.** | |
| 4 | - | **As of: 2026-05-16.** | |
| 5 | - | ||
| 6 | - | How MNW builds, maintains, and draws down financial reserves. The mechanism that lets us keep prices stable (mandate 1) while pricing close to cost (mandate 2). | |
| 7 | - | ||
| 8 | - | This doc is internal. Reserves are mentioned in `guarantees.md` (public) only as a commitment to maintain them — no targets, formulas, or balances are published. | |
| 9 | - | ||
| 10 | - | --- | |
| 11 | - | ||
| 12 | - | ## 1. Why reserves exist | |
| 13 | - | ||
| 14 | - | Two stated mandates conflict directly: | |
| 15 | - | ||
| 16 | - | 1. Prices should not rise. Creators get stability. | |
| 17 | - | 2. Prices should be close to cost-to-deliver. Creators don't fund extraction. | |
| 18 | - | ||
| 19 | - | A single shock to inputs (Hetzner price change, regulatory action, viral bandwidth spike, legal incident) would force a price increase under mandate 2 alone. Reserves let mandate 1 hold by absorbing the shock without passing it through. | |
| 20 | - | ||
| 21 | - | The reserve is therefore a **one-time savings target**, not an ongoing margin. Once built, it persists; the margin that funded it can shrink to near zero. | |
| 22 | - | ||
| 23 | - | --- | |
| 24 | - | ||
| 25 | - | ## 2. Reserve cap | |
| 26 | - | ||
| 27 | - | The target balance at which reserves are "enough": | |
| 28 | - | ||
| 29 | - | $$R_\text{cap} = T_\text{fixed} \cdot F + S_\text{legal} + S_\text{shock}$$ | |
| 30 | - | ||
| 31 | - | | Symbol | Meaning | Current value | Source | | |
| 32 | - | |---|---|---|---| | |
| 33 | - | | $T_\text{fixed}$ | Months of fixed costs to bank | **12 months** | Policy choice — see §7 | | |
| 34 | - | | $F$ | Current monthly fixed burn | **$580/mo** | `expenses.md` (itemized total $579.08, rounded) | | |
| 35 | - | | $S_\text{legal}$ | Legal/regulatory reserve | **$50,000** | Policy choice — see §7 | | |
| 36 | - | | $S_\text{shock}$ | Bandwidth/operational shock reserve | **$5,000** | Policy choice — see §7 | | |
| 37 | - | | **$R_\text{cap}$** | **Target** | **$61,960** | Computed: $580 \cdot 12 + 50{,}000 + 5{,}000$ | | |
| 38 | - | ||
| 39 | - | $R_\text{cap}$ grows mechanically as $F$ grows. It is recomputed when fixed costs change. | |
| 40 | - | ||
| 41 | - | ### Why these numbers | |
| 42 | - | ||
| 43 | - | - **12 months of fixed.** Enough to cover a year of operations during a worst-case revenue interruption (regulatory ban, viral incident causing mass churn, prolonged founder absence). Less is fragile; more is hoarding. | |
| 44 | - | - **$50K legal.** Covers a contested legal incident with attorney representation through resolution. Sourced from rough range in `internal/strategy/pitch.md` legal-cost estimates (pre-quote). Will tighten when quotes land. | |
| 45 | - | - **$5K shock.** Covers a viral month of Hetzner egress overage (~5 TB above bundled) plus modest compute upgrade. Hetzner egress is €1/TB, so this is roughly 50 worst-case-spike months. | |
| 46 | - | ||
| 47 | - | --- | |
| 48 | - | ||
| 49 | - | ## 3. Opportunistic fund ($R_\text{opp}$) | |
| 50 | - | ||
| 51 | - | A separate, bounded bucket for discretionary mission-aligned spending. Distinct from $R_\text{cap}$ — which is the *untouchable safety floor* — $R_\text{opp}$ is the *intentionally spendable* fund for things like: | |
| 52 | - | ||
| 53 | - | - **Event sponsorship** — indie creator conferences, local meetups, aligned events | |
| 54 | - | - **Opportunistic marketing** — sponsored content, collabs, paid placements that drive new creators | |
| 55 | - | - **Charitable contributions** — donations to FOSS projects MNW uses, aligned nonprofits | |
| 56 | - | - **Strategic gifts** — e.g., supporting a creator's emergency fund, helping a partner launch | |
| 57 | - | ||
| 58 | - | | Symbol | Meaning | Current value | Notes | | |
| 59 | - | |---|---|---|---| | |
| 60 | - | | $R_\text{opp}$ | Opportunistic fund cap | **$10,000** | Policy choice — see §8 | | |
| 61 | - | | $\rho_\text{annual}$ | Max % of $R_\text{opp}$ spendable per rolling 12 months | **50%** ($5,000/yr) | Policy choice — see §8 | | |
| 62 | - | | $\rho_\text{incident}$ | Max % of $R_\text{opp}$ spendable in a single decision | **25%** ($2,500) | Policy choice — see §8 | | |
| 63 | - | ||
| 64 | - | ### Spend rules | |
| 65 | - | ||
| 66 | - | - **Per-incident max**: $2,500 (= 25% of $R_\text{opp}$). Above this, requires written justification documented before commitment. | |
| 67 | - | - **Annual aggregate max**: $5,000 in any rolling 12-month window (= 50% of $R_\text{opp}$). Hard cap; once hit, no further opportunistic spend until window rolls forward. | |
| 68 | - | - **Replenishment**: surplus refills $R_\text{opp}$ toward cap after any drawdown, ahead of earn-back credit allocation. So in steady state, $R_\text{opp}$ stays at or near its cap and annual spend = annual replenishment. | |
| 69 | - | - **Categories explicitly out of scope**: founder compensation, ongoing operational costs, hiring (those go through `expenses.md` budget, not this fund). | |
| 70 | - | ||
| 71 | - | ### Decision authority | |
| 72 | - | ||
| 73 | - | | Spend size | Approval | Logging | | |
| 74 | - | |---|---|---| | |
| 75 | - | | ≤ $250 | Founder, single decision | Logged after the fact | | |
| 76 | - | | $250–$2,500 | Founder, single decision | Written justification logged before commitment | | |
| 77 | - | | > $2,500 | Requires explicit reason for exceeding $\rho_\text{incident}$; logged ledger entry; counted against annual cap | Same | | |
| 78 | - | ||
| 79 | - | ### Public disclosure | |
| 80 | - | ||
| 81 | - | Annual summary of $R_\text{opp}$ spend, by category and recipient, published on `/partners` or equivalent. Makes the discretionary spend auditable. (Note: the public disclosure surface itself is a Phase 5 deliverable — if `/partners` doesn't exist when first disclosure is due, the summary is published wherever partnership announcements go.) | |
| 82 | - | ||
| 83 | - | The cap value ($10K) and the spend-rate parameters ($\rho$) themselves are **not** published — they're an internal operational matter. | |
| 84 | - | ||
| 85 | - | --- | |
| 86 | - | ||
| 87 | - | ## 4. Surplus disposition | |
| 88 | - | ||
| 89 | - | Once $R \geq R_\text{cap}$, every additional dollar of surplus has a defined destination, in priority order: | |
| 90 | - | ||
| 91 | - | 1. **Maintain $R_\text{cap}$.** Any drawdown to the safety reserve is topped up first. | |
| 92 | - | 2. **Fill $R_\text{opp}$ to cap.** If the opportunistic fund is below its $10K cap, surplus flows there next. | |
| 93 | - | 3. **Maintain $R_\text{opp}$.** Refill the opportunistic fund after any spend, on a rolling basis. | |
| 94 | - | 4. **Earn-back credit** to creators (continuous return mechanism, committed by 2027-01-01 per memory). | |
| 95 | - | 5. **Price decrease.** When trailing-12-month sustained surplus exceeds the rate needed to maintain (1)-(3) and fund (4) at a target allocation level — evaluate a price drop. | |
| 96 | - | ||
| 97 | - | ### Surplus split in steady state (both reserves full) | |
| 98 | - | ||
| 99 | - | Proposed default: **20% to reserve maintenance buffer / 80% to earn-back credit pool.** | |
| 100 | - | ||
| 101 | - | The 20% maintenance buffer covers both $R_\text{cap}$ top-up after small drawdowns and $R_\text{opp}$ top-up after opportunistic spend. The 80% to earn-back is the continuous return-of-surplus that lets prices stay nominally stable while economic cost-to-creator falls. | |
| 102 | - | ||
| 103 | - | Price decreases are evaluated annually against trailing data; they are discrete events, not formula-triggered. | |
| 104 | - | ||
| 105 | - | ### Fill-time impact of adding $R_\text{opp}$ | |
| 106 | - | ||
| 107 | - | Total reserve target is now $R_\text{cap} + R_\text{opp}$ = $61,960 + $10,000 = **$71,960**. | |
| 108 | - | ||
| 109 | - | At founding-cohort ARPU ($11/creator/mo) with assumed marginal cost $1 and $F = \$580$: | |
| 110 | - | ||
| 111 | - | | N | Monthly surplus | Time to fill $R_\text{cap}$ only ($61,960) | Time to fill $R_\text{cap} + R_\text{opp}$ ($71,960) | | |
| 112 | - | |---|---|---|---| | |
| 113 | - | | 100 | $420 | 148 mo | 171 mo | | |
| 114 | - | | 200 | $1,420 | 44 mo | 51 mo | | |
| 115 | - | | 500 | $4,420 | 14 mo | 16 mo | | |
| 116 | - | | 1000 | $9,420 | 7 mo | 8 mo | | |
| 117 | - | ||
| 118 | - | Adding $R_\text{opp}$ slows fill by ~16% but $R_\text{cap}$ — the safety floor — fills at the same rate as before because it's prioritized. | |
| 119 | - | ||
| 120 | - | --- | |
| 121 | - | ||
| 122 | - | ## 5. Reserve drawdown triggers | |
| 123 | - | ||
| 124 | - | ### $R_\text{cap}$ drawdowns (safety reserve — protect aggressively) | |
| 125 | - | ||
| 126 | - | | Drawdown type | Source bucket | Max single draw | Approval | | |
| 127 | - | |---|---|---|---| | |
| 128 | - | | Operating deficit | $T_\text{fixed} \cdot F$ | Full 12-month buffer | Founder, documented | | |
| 129 | - | | Legal incident | $S_\text{legal}$ ($50K) | Full bucket | Founder, documented | | |
| 130 | - | | Viral bandwidth spike | $S_\text{shock}$ ($5K) | Full bucket | Auto if measured | | |
| 131 | - | | Vendor pricing shock | Discretionary | Cap to whatever shock requires | Founder, documented | | |
| 132 | - | | Extraordinary | Any | Requires written justification | Founder, documented | | |
| 133 | - | ||
| 134 | - | ### $R_\text{opp}$ drawdowns (opportunistic fund — intentionally spendable) | |
| 135 | - | ||
| 136 | - | Per §3 spend rules: per-incident max $2,500, annual aggregate max $5,000. Categories: event sponsorship, opportunistic marketing, charitable, strategic gifts. Each spend logged to ledger. | |
| 137 | - | ||
| 138 | - | ### $R_\text{cap}$ is *not* spent on: | |
| 139 | - | ||
| 140 | - | - Founder salary above the budgeted figure in `expenses.md`. | |
| 141 | - | - Discretionary feature development beyond budgeted dev capacity. | |
| 142 | - | - Routine marketing, paid acquisition, recurring sponsorships (those flow through `expenses.md` budget if approved as ongoing, or through $R_\text{opp}$ if one-off). | |
| 143 | - | - New hires beyond the planned residency pipeline. | |
| 144 | - | ||
| 145 | - | The distinction is intentional: $R_\text{cap}$ exists to survive shocks; ongoing operational categories belong in `expenses.md`; discretionary mission-aligned spending belongs in $R_\text{opp}$. | |
| 146 | - | ||
| 147 | - | Drawdowns from either bucket are logged in a ledger entry (`internal/business/reserve_ledger.md` — TODO when first drawdown occurs). | |
| 148 | - | ||
| 149 | - | --- | |
| 150 | - | ||
| 151 | - | ## 6. Personal-to-company transition | |
| 152 | - | ||
| 153 | - | Right now, founder's $190K personal savings (per `financial_dashboard.md`) is the *implicit* reserve. The company has no separate reserve balance. This is fine until it isn't. | |
| 154 | - | ||
| 155 | - | ### Current phase (pre-$R_\text{cap}$): personal savings is the backstop | |
| 156 | - | ||
| 157 | - | - All surplus from creator subscriptions accumulates in company accounts. | |
| 158 | - | - Company reserve fills toward $R_\text{cap}$ from operating surplus. | |
| 159 | - | - Personal savings backs any shock that exceeds current company reserves. | |
| 160 | - | - Personal savings is otherwise untouched by business operations. | |
| 161 | - | ||
| 162 | - | ### Transition (company reserves cross $R_\text{cap}$) | |
| 163 | - | ||
| 164 | - | When company reserves first reach $R_\text{cap}$: | |
| 165 | - | - Personal savings is freed for non-business use (it was implicit backup; that role is now redundant). | |
| 166 | - | - Company is fully self-insured at the cap level. | |
| 167 | - | - Surplus disposition rule (§3) activates. | |
| 168 | - | ||
| 169 | - | ### What is **not** done | |
| 170 | - | ||
| 171 | - | - No founder loan from personal savings to company (avoids comingling — same principle as Stripe Connect Standard MoR-by-creator). | |
| 172 | - | - No equity issuance from the company in exchange for the personal-savings backstop (no investors, ever, per `economics.md`). | |
| 173 | - | - No interest accrual on the implicit backstop. | |
| 174 | - | ||
| 175 | - | The personal-savings backstop is a gift in the formal sense: it costs the company nothing and creates no obligation. | |
| 176 | - | ||
| 177 | - | --- | |
| 178 | - | ||
| 179 | - | ## 7. Review cadence | |
| 180 | - | ||
| 181 | - | | Review | Frequency | Inputs | Output | | |
| 182 | - | |---|---|---|---| | |
| 183 | - | | Reserve balance check | Monthly | Bank balance ($R_\text{cap}$ and $R_\text{opp}$), fixed-cost actual | Update header date | | |
| 184 | - | | $R_\text{cap}$ recomputation | When $F$ changes by >10% | Updated `expenses.md` | New $R_\text{cap}$ value | | |
| 185 | - | | $R_\text{opp}$ rolling spend check | Monthly | Trailing-12-month spend total | Confirm under $\rho_\text{annual}$ cap | | |
| 186 | - | | Surplus disposition review | When $R$ first reaches $R_\text{cap}$ | Reserve balance, trailing surplus | First $R_\text{opp}$ allocation; first earn-back allocation; first price-change evaluation | | |
| 187 | - | | Drawdown ledger entry | At each drawdown | Cause, amount, expected replenishment | Logged | | |
| 188 | - | | Annual $R_\text{opp}$ disclosure | January | Trailing-12-month $R_\text{opp}$ spend, by category and recipient | Published summary | | |
| 189 | - | | Annual policy review | January | Full year of operating data | Updated `reserve_policy.md` and `pricing.md` | | |
| 190 | - | ||
| 191 | - | --- | |
| 192 | - | ||
| 193 | - | ## 8. Open decisions | |
| 194 | - | ||
| 195 | - | 1. **$T_\text{fixed}$**: 12 months of fixed costs is current proposal. Alternatives: 6 months (faster fill, more shock-exposed), 18 months (slower fill, more conservative). | |
| 196 | - | 2. **$S_\text{legal}$**: $50K is rough. Should be tightened against actual attorney quotes (see `remediations.md` Phase 5.2). May need to be higher if any pre-launch incident is anticipated. | |
| 197 | - | 3. **$S_\text{shock}$**: $5K is a small bandwidth buffer. Should be reviewed against any pre-launch load testing that estimates viral-spike worst case. | |
| 198 | - | 4. **$R_\text{opp}$**: $10K cap is current proposal. Alternatives: $5K (more conservative, fewer opportunities per year), $20K (allows more aggressive sponsorship/charitable activity), $50K (significant indie-marketing presence). | |
| 199 | - | 5. **$\rho_\text{annual}$**: 50%/yr is current proposal ($5K/yr at $10K cap). Could be 25% (more conservative, slower spend), 100% (could fully replenish each year — but no buffer if surplus disappears). | |
| 200 | - | 6. **$\rho_\text{incident}$**: 25% per single decision is current proposal ($2,500 max). Alternatives: 10% ($1,000, forces splitting larger spends), 50% ($5,000, allows single larger commitments). | |
| 201 | - | 7. **Surplus split ratio (steady state)**: 20/80 (reserve-maintenance/earn-back) is a default. Could be 10/90 once both reserves are comfortably held. Could be 50/50 in a high-volatility environment. | |
| 202 | - | 8. **Earn-back credit allocation methodology**: how surplus translates to credits per creator. Proportional to tier price? Equal across creators? Proportional to GMV they drove? Decision deferred to earn-back design phase (committed by 2027-01-01). | |
| 203 | - | 9. **Whether to publish the reserve framework publicly**. Current proposal: no specific reserve dollar values, only commitments in `guarantees.md`. The annual $R_\text{opp}$ disclosure is published per §3. Alternative: publish $R_\text{cap}$ formula publicly to demonstrate the discipline. Tradeoff: transparency vs. operational flexibility. See also `/health` financial-info question for related decisions on `economics.md` and dashboard-style transparency. | |
| 204 | - | 10. **Transition trigger**: should the personal-to-company transition wait for $R_\text{cap} + R_\text{opp}$ both filled, or just $R_\text{cap}$? Current proposal: $R_\text{cap}$ only. | |
| 205 | - | ||
| 206 | - | --- | |
| 207 | - | ||
| 208 | - | ## 9. References | |
| 209 | - | ||
| 210 | - | - `pricing.md` — how reserves interact with pricing decisions | |
| 211 | - | - `expenses.md` — current $F$ (fixed monthly burn) | |
| 212 | - | - `financial_dashboard.md` — current personal savings and runway | |
| 213 | - | - `chargeback_protection_fund.md` — a separate reserve for chargeback float; not part of $R_\text{cap}$ or $R_\text{opp}$ | |
| 214 | - | - `partnerships.md` — partnership criteria (disclosure mechanism for $R_\text{opp}$ spend is internal SOP, not currently committed publicly in partnerships.md) | |
| 215 | - | - `assumptions.md` — A26, A27, A28, A30, A31 (cost-to-deliver, ticket categorization, cohort metrics, reserves) | |
| 216 | - | - `sops/pricing-change-decision.md` — protocol for using reserve data in pricing decisions | |
| 217 | - | - `sops/reserve-management.md` — drawdown and $R_\text{opp}$ approval workflow | |
| 218 | - | - `guarantees.md` (public) — the commitments backed by this policy |