# Car Parts Price Comparator — Monetization Playbook (Open-Source, Local-First)

**Status:** Draft v1 · 2026-07-14
**Companion documents:** `MONETIZATION.md` (the economics analysis — *why* each engine works or doesn't; written for the hosted model), `DISTRIBUTION.md` (the open-source + desktop/mobile distribution this playbook assumes).
**Scope:** The operational, step-by-step version: what to do, in what order, with what expected numbers. Where the distribution pivot changes `MONETIZATION.md`'s conclusions, this document says so explicitly and wins.

> **Supersession note (2026-07-16):** The app no longer adds UTM parameters or records searches/clickouts. Steps below that depend on attribution are historical and are not active implementation guidance.

**The one-line strategy:** free open-source app as the distribution engine → affiliate defaults as the passive revenue floor → paid convenience builds → "we keep the adapters alive" as the only thing with a real price tag, sold only when someone asks.

**The free-rider clause (accepted up front):** nothing stops a mechanic — or anyone — from using the free binary forever. No license prevents *use* (AGPL constrains hosts, not users), and we don't try. Every phase below either monetizes free use itself (Phase 1), sells convenience alongside it (Phase 2), or sells the one thing a free download can't include — ongoing maintenance labour against adapter rot (Phase 3). Heavy free users are an asset, not a leak: under Phase 1 they *are* the revenue.

---

## Phase 0 — Prerequisites (no money yet)

Everything here precedes the first euro and most of it is already planned elsewhere.

1. **Ship the distributable** per `DISTRIBUTION.md` §7: adapter purity refactor → Electron go/no-go → shell → pre-publication scrub → repo public + first release. No monetization step makes sense before there is something to download.
2. **A landing page** (one static page: what it does, screenshots, download buttons, GitHub link). Needed not for users but for **affiliate network applications** — every network asks for a URL and a traffic story, and a bare GitHub repo reads poorly to their reviewers. GitHub Pages is fine.
3. **Tip jar** — GitHub Sponsors + a Ko-fi/PayPal.me footer link. Per `MONETIZATION.md` §7.4 this is an infra offset, not an engine; it costs an hour, set it up and forget it.
4. **Add UTM tags to outbound links now.** `utm_source=<appname>&utm_medium=comparator` on every store clickout. This costs nothing, needs no server, and quietly builds the Phase-4 evidence base **inside each store's own analytics** — replacing the dead `/out` measurement (see Phase 4).
5. **Stay a private person for now.** No entity, no registration, until recurring money actually appears (see "Latvia admin track" below).

**Gate to Phase 1:** repo public + a downloadable release + landing page live.

---

## Phase 1 — The passive floor: affiliate defaults (months 0–3)

The app decorates outbound links with the maintainer's affiliate tag, locally, no server involved. Free heavy users (the mechanic) generate revenue on every purchase they make anyway. This is the Firefox/Brave model: open source, monetized by defaults.

1. **Inventory programs.** Reality check from `MONETIZATION.md` §5.1: Autodoc's affiliate program covers ~26 EU markets **but not LV/LT/EE**, and the part-number product feeds sit on a gated comparison-shopping-partner track. So this phase has two parallel workstreams:
   - **a. Network sweep (self-serve, days):** register as a publisher on Awin, Tradedoubler, Webgains, Admitad, TradeTracker; search each for *any* auto-parts program that either covers Latvia or ships to it. Expect thin results; document what exists.
   - **b. The BD email (the actual unlock, months):** write to Autodoc's affiliate/partnerships team asking specifically about LV-market participation or the CSS/feed-partner track. The pitch: "10k installed users in a market where your program has no presence; we send you buyers only when you're cheapest." Rejection costs nothing; acceptance unblocks the best engine we've identified. Repeat for kfzteile24-class retailers.
2. **Implement link decoration.** Affiliate/UTM parameters live in a single config file in the repo; applied at click time; opens in the system browser (network redirectors need real browser cookies — an in-app webview would break attribution).
3. **Disclose transparently.** README + an in-app "About" line: *"Store links include the maintainer's affiliate tag, which funds development at no cost to you. Forks may remove it."* Transparency is what separates this from the Honey scandal (which was about *hiding* injection, not doing it). Yes, a fork can strip the tag; in practice approximately nobody forks, and defaults carry >95% of usage.
4. **Honest expectations.** CPA at ~8%/4% with a 30-day cookie, average parts basket €60–120, and a few percent of clickouts converting: even 1,000 active users produce **tens to low hundreds of €/month**, and that *only if* workstream (b) lands. If no program accepts, this floor is €0 — proceed to Phase 2 regardless; nothing downstream depends on it.

**Gate to Phase 2:** none — Phase 2 starts whenever the Android build exists; the phases overlap.

---

## Phase 2 — Convenience purchases (months 3–6)

Selling the *same* free software at points of convenience. Nobody is stopped from getting it free; some people pay because paying is easier or feels right.

1. **The "Conversations model" on Android:** identical app, **free on F-Droid and GitHub Releases, €4.99 on the Play Store**. This reliably converts "I'd like to support this" into money at the moment of install, and beats the tip jar because it's a purchase, not a donation. Requires the Capacitor build (`DISTRIBUTION.md` §3.2) and a €25 one-time Play developer account.
2. **Optionally the same on Windows:** free installer on GitHub, a paid listing on the Microsoft Store. Lower expected volume; do it only if listing effort is trivial after the Play Store run.
3. **GitHub Sponsors tiers** with honest, cheap perks: name in README, priority issue triage. Release binaries may lag the source by a week for non-sponsors if we ever want a sponsorware lever — but don't build gating machinery now.
4. **Honest expectations:** at Latvian scale, tens of sales — enough to cover the developer accounts and hosting of nothing. This phase is about capturing goodwill, not building revenue.

**Gate to Phase 3:** *pull, not push* — the first workshop (or second) that emails asking for an invoice, support, or a feature. **Do not build the workshop tier speculatively.**

---

## Phase 3 — The workshop tier: maintenance-as-a-service (month 6+, on demand)

What a workshop buys is not software (the binary is free) — it is **the tool still working on Tuesday morning.** This codebase decays unusually fast (adapter rot: store redesigns, CF tightening, endpoint moves — rd24 broke *between probe and build*), and a fork inherits the same rot and the same labour bill. Maintenance is the structurally fork-proof product.

**The offer (draft):** €25/month per workshop location —
- **Adapter-fix SLA:** paying customers get broken-store fixes targeted within 3 business days (free users: whenever). This is the core promise; price the SLA, not the code.
- **Email support** with a real response time.
- **A proper invoice** — never underestimate this; some workshops pay €25/month purely because expensing beats explaining a GitHub download to their accountant.
- **Later, if asked:** multi-seat purchase-plan sync across the shop's computers. Note this needs a small hosted sync service — hosting *the user's own plan data* is legally clean (nothing scraped is stored centrally; the local-first legal posture of `DISTRIBUTION.md` §6 is preserved).

**Mechanics:**
1. Add a "For workshops" section + price to the landing page. That's the entire build until someone pays.
2. **Payment rails: Paddle** (merchant of record — handles EU VAT/OSS across countries, ideal for a solo dev) over raw Stripe. Decide at first customer, not before.
3. **Gating in an open-source repo:** don't fight it. Value lives service-side (SLA, support, sync); any in-app "pro" flag is an honor-system license key, Sublime-style — trivially bypassable in an open codebase and that's fine, because businesses that need the invoice won't bypass it.
4. **At the first recurring customer:** enter the Latvia admin track below.

**Honest ceiling:** Latvia has on the order of a couple thousand independent workshops; open-core conversion runs 1–5% even for successful projects. 3% × 2,000 × €25 ≈ **€1,500/month at full saturation** — a funded hobby or a nice side income, not a company. The ceiling rises only with geographic expansion (Phase 5).

---

## Phase 4 — Local-store CPA, resurrected via UTM (opportunistic)

`MONETIZATION.md` §5.2's pitch ("I sent you 400 attributable buyers last month") assumed our central `/out` log as evidence. The distributed model killed that log — but Phase 0 step 4 replaced it with something *better positioned*: the evidence now accumulates **in the store's own analytics** (`utm_source=<appname>` in their GA/Matomo), which they trust more than our numbers by definition.

1. Let UTM data accumulate for months while Phases 1–3 run.
2. When install volume is real, email partsale/carparts/eoltas: *"Filter your analytics for `utm_source=<appname>` — that's us. Want to formalize a CPA on it?"*
3. Per `MONETIZATION.md` §2, only CPA (pay per attributed sale), never CPC; small stores may need help setting up conversion tracking — more relationship overhead per euro than Phase 1, which is why this phase is opportunistic, not core.

---

## Phase 5 — The 12-month decision gate

Restating `MONETIZATION.md` §8's discipline for the new model: **no drift.** At ~12 months after going public, tally the engines:

- **Affiliate floor + convenience sales + workshop MRR ≥ enough to care** (suggested bar: covers all costs + meaningfully pays for adapter labour, e.g. €500+/month) → consider **expansion to LT/EE**: new store sets, new adapter batches, ~3× the audience and the affiliate base. This is the only move that raises every ceiling at once.
- **Below the bar** → settle deliberately: the project continues as a self-funding (or cheap) open-source hobby with the tip jar and whatever affiliate trickle exists, and that is a *fine outcome* — unlike `MONETIZATION.md` §7.4's hosted free utility, the local-first model has **no standing bill and no operator liability**, so "unfunded" no longer means "existential." Sunset is no longer the forced alternative; it's merely an option.

---

## The Latvia admin track (runs alongside, triggered by money)

Not legal/tax advice; rates and thresholds drift — confirm each step with VID or an accountant *when its trigger fires.*

| Trigger | Step |
|---|---|
| Tips / one-off trickle (Phases 0–2) | Nothing to register for occasional small income; keep records. Verify current VID treatment of hobby-scale income when it starts. |
| First **recurring** revenue (Phase 3, or steady Phase 1) | Register economic activity: **saimnieciskā darbība** with VID (simplest) or a **mazkapitāla SIA** (limited liability, ~€1 capital — the C&D-resilience option). Get an accountant; compare the micro-enterprise tax regime vs. standard IIN at your actual numbers. |
| First **EU cross-border B2B** money — affiliate networks (Awin etc.) pay from abroad | EU cross-border services generally require **VAT registration for EU transactions regardless of the domestic turnover threshold** (~€50k). This fires *earlier* than intuition suggests — ask the accountant before the first Awin invoice, not after. |
| Consumer sales (Phase 2/3) | Prefer **merchant-of-record** channels (Play Store, Paddle) that collect and remit consumer VAT themselves — this is most of why Paddle over Stripe. |
| Any C&D or legal contact | Per `MONETIZATION.md` §7.4: with revenue, legal is a cost of doing business. A mazkapitāla SIA + a retainer-free relationship with one lawyer is the cheap insurance; establish the contact when Phase 3 money starts, not when the letter arrives. |

---

## Summary: the whole playbook on one screen

| # | Action | Cost | Expected €/month | Trigger |
|---|---|---|---|---|
| 0 | Ship distributable, landing page, tip jar, UTM tags | hours | ~0 | now |
| 1a | Affiliate network sweep + link decoration | days | 0 until a program accepts | repo public |
| 1b | BD email to Autodoc-class for LV program/feed | an email, then patience | tens–low hundreds *if* it lands | repo public |
| 2 | Play Store €4.99 build (free on F-Droid/GitHub) | days + €25 | tens | Android build exists |
| 3 | Workshop tier: SLA + support + invoice, Paddle | landing-page section, then on demand | €25/customer; ceiling ≈ €1,500 | **first inbound ask** |
| 4 | Local-store CPA pitch off *their* UTM analytics | emails | modest, per-store | real install volume |
| 5 | Expand LT/EE **or** settle as funded hobby | new adapters | ~3× ceilings | 12-month gate |