Skip to content

Issue #41: Foundation — monetisation + pricing model

  • Issue: #41
  • Started: 2026-04-28
  • Completed: in progress

Goal

Ship two docs:

  1. RFC-0008 at docs/rfc/0008-monetisation.md — recommends a primary monetisation stream + a fallback for 961tech, with a comparison matrix across CPS / CPC / hybrid / featured-placement on Beirut-friction, scaling, retailer-cooperation requirements, and unit-economics ranges. Calibrated to the price-sensitive primary personas ($600-1.8K builds) per personas.md §6.3 and to the bilateral-relationship reality flagged in retailers.md §7 Open question #1 (every Lebanese retailer in the audit returned Unknown for affiliate program).
  2. Reference doc at docs/reference/monetisation.md — per-revenue-stream profile (how it works, who pays, retailer cooperation needed, expected revenue range, time-to-positive-cashflow estimate). The reference is the lookup; the RFC is the decision.

The original aggregator design spec §4.1 already named CPS 1.5% primary + $0.15 CPC fallback + $50-200/mo featured (optional). This ticket either ratifies that with sourced unit economics or proposes a different shape and explains why.

Out of scope

  • No code. Stay in docs/. No src/ or prisma/ or tests/ touches.
  • No push, no PR. One atomic commit on feat/issue-41 and stop. Per ticket workflow.
  • No implementation tickets. #17 affiliate reconciliation S2S postback is the eventual implementation track once a CPS deal is signed; the RFC references it but doesn't reopen it.
  • No legal / VAT decision. #40 handles tax / income classification. The RFC flags VAT impact at a stream level but doesn't prescribe.
  • No retailer outreach copy. The RFC may sketch what a Stage-3 pitch looks like as part of the bilateral-deal reality, but actual outreach scripts are post-launch operational work.
  • No fabricated revenue numbers. Use ranges + label them as estimates per ticket constraint.

Approach

Three-phase: parallel competitor verification → RFC draft → reference draft → atomic commit.

  1. Verify competitor monetisation claims. The original spec cites Skroutz 7-12% commission + €469 setup, Idealo €0.24/click, PCPartPicker 0.5-1%, Pricena CPS/CPC. Per ticket spot-check methodology, every claim used in the RFC needs a named source — public ToS / FTC filings / news / disclosure pages / well-cited industry write-ups. Dispatch parallel subagents per region (MENA, South Asia, LatAm, plus a "verify-the-spec-citations" agent) so the wall-clock cost is one fetch.
  2. RFC-0008 draft. Compare CPS / CPC / hybrid / featured-placement on the four ticket-named axes (Beirut-friction, scaling, retailer-cooperation requirements, unit economics). Recommendation = a primary stream + a fallback + a clear "what would change my mind" decision-flip condition. Honor the personas §6.3 LTV/receptivity table and the retailers §7 Unknown-affiliate-program reality.
  3. Reference monetisation.md draft. One section per stream (CPS, CPC, hybrid, featured-placement, B2B/SMB tier, data products). Each: how it works, who pays, retailer cooperation needed, expected revenue range, time-to-positive-cashflow estimate. Cross-references baked in.
  4. Indexes updated. docs/rfc/index.md gains a row; docs/reference/index.md gains a row.
  5. Verify with mkdocs build --strict.

Why this approach: parallel competitor research is the long-running expensive bit; doing it concurrently with the doc skeleton work means total wall-clock is bound by the agents' fetch times, not their sum. The RFC stays small (~600-900 lines) by deferring per-stream operational detail to the reference doc.

Steps

  • Step 1: Stub the plan, RFC, and reference docs
  • Create docs/plans/2026-04-28-issue-41-monetisation.md (this file).
  • Stub docs/rfc/0008-monetisation.md with frontmatter + section headers from the RFC template (Summary, Motivation, Proposal, Trade-offs, Alternatives, Open questions, Implementation plan, Out of scope).
  • Stub docs/reference/monetisation.md with frontmatter + section headers (Scope, Per-stream profiles, Cross-cutting, Open questions, See also).

  • Verification: mkdocs build --strict passes against the stubs (frontmatter is well-formed; no broken refs).

  • Step 2: Dispatch parallel competitor-verification subagents

  • Use superpowers:dispatching-parallel-agents. Four agents in one message:
    1. MENA — Pricena (UAE/Egypt/KSA), eXtra (KSA), Souq.com / Amazon.ae partner programs. Goal: source-level citation for "CPS / CPC / hybrid / fee structure" per platform. Note: the competitive-landscape.md §2.10 Pricena entry already says "rates not public" — the agent confirms or refutes that and digs for any 2024-2026 disclosure.
    2. South Asia — Daraz (PK/BD/MMR — Alibaba-owned), Smartprix (IN), MySmartPrice (IN). Specifically: how aggregators monetise in markets where retailer affiliate cooperation is bilateral or thin.
    3. LatAm — MercadoLibre (regional marketplace + comparator dynamics), Buscapé / Zoom (BR price comparators). Same goal — source-cited monetisation models.
    4. Verify-the-spec citations — confirm or refute the spec's claims:
    5. Skroutz: 7-12% commission per category + €469 setup fee
    6. Idealo: ~£0.24/click
    7. PCPartPicker: 0.5-1% effective via Amazon Associates + retailer partnerships, plus their public Industry Affiliate Code of Conduct
    8. Geizhals: pure CPC, no bidding
  • Per-agent prompt: focused, self-contained, says "return source URL + claim quote in JSON-ish structured form; if a claim is unverifiable from public sources within 15 min of fetching, say unverifiable and explain why."

  • Verification: 4 reports received; every cited claim in the RFC will trace to one of these reports' URLs OR be marked as estimate / industry pattern, no public source.

  • Step 3: Write RFC-0008

  • Body sections, in order:
    1. Summary (one paragraph, 30-second read).
    2. Motivation — anchored in: spec §4.1 already proposes 1.5% CPS / $0.15 CPC / $50-200 featured, but #30 audit confirmed every retailer is Unknown on affiliate program (relationships are bilateral). Personas §6.3 says CPS is universally a stronger fit than CPC for primary cohorts; first-timer LTV is single-build; Office IT is high-LTV outlier; Diaspora unlock is foreign-card-payment partnership. Ticket says monetisation that taxes the buyer is a non-starter — rules out paid-tier-for-buyers in M1/M2.
    3. Proposal — primary + fallback + featured-placement + B2B/SMB tier + data products (deferred). Comparison table on Beirut-friction × scaling × retailer-cooperation × unit-economics-range. The recommendation hangs on which side wins on bilateral-friction. Spec the decision-flip conditions (e.g. "if Wave-1 retailer outreach fails to land any S2S postback by Month 6, demote CPS to fallback and run on CPC + featured").
    4. Pricing model for retailers (cost side) — adopt Free organic + paid premium tier per spec §6.1 four-stage onboarding ladder. Reject pure-pay (catalog dies) explicitly.
    5. Cross-cutting — currency to charge in (USD per ADR-0004), VAT impact (defer specifics to #40), Lebanese settlement rails (Whish corporate $30k cap; USDT TRC20 fallback per spec §7).
    6. Trade-offs — running CPS + CPC reconciliation in parallel has real ops cost. Featured placement has trust risk if poorly labeled (Idealo €465M lawsuit precedent per competitive §2.4). B2B tier is a different sales motion than B2C aggregator — surface but defer.
    7. Alternatives — pure CPC default, pure CPS default, marketplace commission (Skroutz path), no affiliate (sponsorships only). Each with one-paragraph why-rejected.
    8. Open questions — surface anything that crosses into "MASTER hasn't expressed this preference" territory (see ticket "Stop and ask if" clause). Three candidates: (a) "should we run featured placements that risk eroding trust?" — Lebanese retail norms are tolerant per ticket framing, so this is decidable; (b) "user-first-free-aggregator vs monetisation-first SMB tool" — values-driven; © any retailer-relationship-shaped blocker.
    9. Implementation plan — checklist mapping to issues #17 (S2S postback), #16 (admin tools / B2B), #14 (price-drop alerts subscription gate consideration), #28 (where featured placements surface), #40 (legal / VAT). One-line per follow-up.
    10. Out of scope — implementation, legal-VAT detail, outreach scripts.
  • Style: match RFC-0004's information density. Tables for comparisons. Inline citations with source URLs in footnote-style.

  • Verification: every monetisation claim that names a competitor traces to either Step 2's verified URL or a clearly-labelled estimate / industry pattern. Zero invented numbers.

  • Step 4: Write reference monetisation.md

  • Body sections, in order:
    1. Scope & method — what this is, sources, honest limits (Lebanese-retailer-specific affiliate willingness is Unknown per #30; outreach plan is the unblocker).
    2. Per-stream profiles — one section each for: CPS, CPC, hybrid, featured-placement, B2B/SMB tier, data products. Each section: how it works, who pays, retailer cooperation needed, expected revenue range, time-to-positive-cashflow estimate, references.
    3. Cross-cutting — currency, VAT, settlement rails, trust patterns (sponsored-labeling, code-of-conduct page). Mostly thin pointers to sister docs.
    4. Open questions — Lebanese retailer affiliate willingness; outreach plan; per-stream telemetry needs.
    5. See also — RFC-0008, spec §4.1, competitive-landscape §3.5, personas §6.3, retailers §7 #1.
  • Style: matches competitive-landscape.md and personas.md layout (reference index already linked).

  • Verification: every per-stream profile is non-empty; every revenue-range carries an "(estimate)" or "(industry pattern)" tag if not source-cited.

  • Step 5: Update indexes

  • docs/rfc/index.md — add RFC-0008 row.
  • docs/reference/index.md — add monetisation.md row.

  • Verification: both indexes link to the new docs; alphabetical / numerical order preserved.

  • Step 6: Gate — mkdocs build --strict

  • Run mkdocs build --strict from project root.
  • Expected: clean build. Strict mode catches broken cross-refs.

  • If failure: fix the broken link/anchor and rebuild. Don't commit until clean.

  • Step 7: Atomic commit

  • git add docs/plans/2026-04-28-issue-41-monetisation.md docs/rfc/0008-monetisation.md docs/reference/monetisation.md docs/rfc/index.md docs/reference/index.md
  • Commit message: docs(rfc): add monetisation RFC + reference (#41) — closes #41 via Closes #41 line in body.
  • Verification: git status shows clean tree post-commit; git log -1 --stat shows only the 5 docs files touched. No push, no PR.

Risks

Risk Likelihood Mitigation
Competitor-verification subagents return "unverifiable" for most spec citations Medium Use unverified claims explicitly tagged industry pattern, no public source in the RFC. Don't drop claims; flag them.
RFC turns into a values-driven decision MASTER hasn't expressed (e.g. featured-placements-yes-or-no) Medium-high Ticket "Stop and ask if" clause. Surface as Open Question with options ranked recommend-first; do NOT silently pick.
Lebanese retailer affiliate willingness is genuinely unknowable from desk research High (acknowledged) Acknowledge directly per ticket constraint; recommend an outreach plan as part of RFC implementation list.
Spec's 1.5% CPS feels too low against verified peer rates Low-medium The persona research already shows Lebanon is price-sensitive ($600-1.8K builds); higher CPS pressures retailers to pass cost. Stay disciplined to the persona constraint.
RFC + reference duplicate each other Medium Lock the split: RFC = decision + recommendation + alternatives. Reference = lookup table per stream. If a sentence belongs in both, it goes in reference and the RFC links.
Subagent fetches hit anti-bot / paywall Medium Same fallback as #30 retailer audit — if a source is blocked, agent says so; we cite from training data with (per industry coverage as of YYYY-MM) tag and disclose the limit.

Tests

No code → no test additions. The doc passes if mkdocs build --strict succeeds (Step 6 gate).

Doc updates

  • RFC: new docs/rfc/0008-monetisation.md
  • Reference: new docs/reference/monetisation.md
  • RFC index: row added
  • Reference index: row added
  • Architecture: not changed
  • ADR: none — RFC remains in Draft status pending MASTER signoff; ADR comes after acceptance
  • Glossary: only if a new term emerges (CPS / CPC / S2S postback are already glossary candidates from #17 — confirm)
  • Issue body: closing comment on #41 with commit SHA + summary

Rollback

git revert <sha> removes both docs + index rows. No code or schema state to undo.