Proposed deltas to OpenRally DECISIONS.md based on wecourts intel

TLDR

WeCourts is a Dubai padel-tournament-ops platform shipping ~5 features/month on the same stack as us. On a 6-12 month collision course with OpenRally in SEA (tighter timeline than originally estimated — their country dropdown is full ISO-3166, they're a flag-flip from launching here). Twelve concrete deltas to DECISIONS.md proposed below, distilled into twelve decision-asks for you — three strategic (posture, bracket-format breadth, rating-algorithm non-goal) and nine tactical/feature. Phase 3 organizer-walk paused at a 2nd gate: manual approval via WhatsApp — see BLOCKERS.md.

The three decisions that matter most:

• D1 — public competitive posture (yes / no / hybrid)
• D2 — Groups+KO + Direct Advance + MGG in v0.6 (3-4 weeks eng)
• D3 — re-confirm or revisit the "no OpenRally rating algorithm" v1 non-goal

The nine tactical/feature decisions (v0.6 unless noted): WhatsApp+LINE deep-link templating · LFP with structured padel meta · Shareable player profile URL · Multi-currency · Multi-organizer RBAC (v0.7) · Public roadmap · Self-serve organizer onboarding · Two-persona organizer model (v0.7) · Federation partnership framework (v3-v4).

Three new deltas added by Phase 3 evidence: D8 (self-serve organizer onboarding), D9 (two-persona model), D10 (federation partnerships) + supporting D11 (dedupe-search) and D12 (identity-graph foundation v0.7).

Read order if you have 10 minutes: TLDR (this) → Executive Summary → Strategic Reframe → Decision Asks → "Post-onboarding-walk addendum" section. Skip the per-delta detail unless you're saying Yes.

Executive Summary

1. WeCourts is real, on a 6-12 month collision course with OpenRally in SEA (revised down from 12-24mo after Phase 3 walk), and shipping ~5 features per month. Dubai-based padel-only platform on Supabase + Cloudflare (same stack as us — Supabase project URL uptheqepffmurgysqzal.supabase.co directly visible in their HTML preconnect), backed by Sami AlSayyed (also CEO of ShortPoint, 70+ engineers parent), live in 8 MENA + Pakistan with explicit "more countries soon" — and their onboarding's country dropdown is already full ISO-3166 (Thailand, Singapore, Malaysia, Indonesia all selectable). Federation partnerships LOCKED (Egypt Padel Fed + Jordan Tennis Fed). Their WPPR identity graph + Operator Console are real moats (identity graph CONFIRMED via Phase 3 walk — our test account got Nestor's Thai phone auto-resolved); their duplicate-profile / broken-merge / wrong-attribution pain is real exposure.
2. Three low-cost / high-leverage features should land in v0.6 to close the gap before they ship in SEA: locale-aware WhatsApp + LINE deep-link templating (Delta D2), Looking-for-Partner with structured padel meta (Delta D3), and shareable rich-preview player profile URLs (Delta D6). Each is <1 week eng. Each lifts player acquisition + retention.
3. The biggest functional gap is bracket-format breadth. WeCourts ships Groups+KO with Direct Advance + MGG. OpenRally v0.5 ships single-elim only. Recommend Delta D1: Groups+KO in v0.6 (~3-4 weeks eng) — without it, serious padel organizers can't run their typical 12 / 14 / 18 / 26-team tournaments on OpenRally at all.
4. One strategic non-goal deserves explicit re-confirmation, not silent inheritance. DECISIONS.md says "No OpenRally-built rating algorithm (v3 integrates external)." The fence is reasonable; it's also a competitive vulnerability given wecourts's WPPR is their moat. Decision 3 surfaces this. (Payments — DECISIONS.md v5 plan — is touched by Decision 1's posture choice; if we go publicly competitive, v4 may be more appropriate.)
5. One strategic posture decision matters more than any feature. Are we publicly competing with wecourts (shaping marketing, partnerships, roadmap urgency around being "the SEA wecourts isn't") or keeping the competitive lens internal-only? Decision 1 below.

Strategic Reframe

Does wecourts shift our wedge? Yes — but not where you'd guess.

What does NOT change

• Sport scope: still padel-first (wecourts validates the bet, doesn't shift it).
• Geographic scope: still Thailand-first / Asia-Pacific (wecourts isn't there yet, and our i18n + relationships are a real advantage).
• Stack: still Next.js 16 + Supabase + Cloudflare (wecourts uses the same — confirmation, not contradiction).
• Top-down strategy: still organizer-first product where TPS owns the player mobile surface.

What DOES change

• Functional breadth ambition. We can no longer ship single-elim only and call it v1. WeCourts has set a higher floor: Groups+KO with Direct Advance + MGG must be in v1 to be a credible tournament-ops product for serious organizers. (Their Featurebase shows organizers running 12 / 14 / 18 / 26 / 27-team tournaments needing MGG / Direct Advance — these are the actual operational dragons.)
• Trust-as-product. WeCourts's duplicate-profile and rating-dispute pain is open and visible (Featurebase, 8-18 days old). Our wedge in SEA is to ship the clean identity graph from day 1 — mobile OTP at registration, canonical name normalization, public merge tool, audit trail. This becomes a marketable differentiator, not just hygiene.
• WhatsApp / messenger-native UX. WeCourts won MENA with WhatsApp-native flows (deep-link templating, click-to-chat clubs, WhatsApp communities). LINE dominates Thailand, WhatsApp is huge in Indonesia. OpenRally's messenger story is unwritten — we should write it WhatsApp+LINE-native from v0.6, not bolted-on at v1.
• Time-to-market urgency. We previously had no benchmarked competitor. Now we have one shipping ~5 features per month. Our v0.5 → v1.0 roadmap should compress, not stretch.

What "winning" looks like vs wecourts

Not parity — they're 12-18 months ahead on padel-tournament-operator polish. Winning means:

• We are the default for SEA padel by v1.0 (target Aug-Oct 2026 based on current OpenRally cadence).
• We are visibly i18n-better, identity-graph-cleaner, accessibility-stronger than wecourts on every dimension a serious organizer evaluates.
• We have operator collaboration RBAC and Groups+KO with MGG + Direct Advance in v0.7 or earlier.
• We have an external rating partnership (FIP-Asia / national federation) lined up by v3 — not a half-baked own algorithm, but not 100% dependent on a single 3rd party either.
• Payments: per DECISIONS.md, still v5. If Decision 1 (posture) puts us publicly competitive with wecourts, this may warrant moving up to v4 — flagged as Decision-ask-derived rather than a unilateral product call.

If we ship all of the above within 9 months, we're ahead in SEA before they arrive.

Concrete Deltas to DECISIONS.md

Each delta below references the existing DECISIONS.md section, names the proposed change, anchors rationale in wecourts evidence, declares feasibility flags from Designer / Lead Engineer / Security lenses, and proposes a feature-flag rollout sequence.

Delta D1 — Add Groups+KO format to v0.6 (was: implied single-elim only through v1)

Current plan says: DECISIONS.md §v0.5 public-bracket + organizer-Draw-tab — exclusively single-elimination knockout (W46-W51), bracket library @g-loot/react-tournament-brackets, draw sizes ≤32.

Propose: Land Groups+KO format in v0.6 with the following sub-features: - Configurable group count (2 / 4 / 8 groups) - Configurable Top-N qualification (Top 1 / 2 / 3 per group) - Direct Advance (uneven group sizes: smaller groups auto-qualify all teams) - Minimum Games Guarantee (MGG) for awkward team counts (12, 14, 18) via Pre-rounds

Rationale (wecourts evidence):

• WeCourts ships both Top 2 (raw-html/29-event-5GLP.text.txt) and Top 3 (raw-html/30-event-N3UE.text.txt) qualification — configurable
• Direct Advance shipped 2026-04-22 (raw-html/34-featurebase-changelog.text.txt Apr 22) — eligible for team counts 10/11/20/21/22/23/26/27, which are common social-tournament sizes
• MGG shipped 2026-04-17 — applies to 12/14/18 — every team plays ≥3 matches
• The Wayback timeline (screenshots/23-wayback-2022.png → today) confirms these features are NEW — organizers ran tournaments without them for years. So we know they're worth shipping but not life-or-death.

Feasibility flags:

• Designer: Medium. Adding 4 new structures to the tournament-create form. Existing v0.3 W27 tournament-form pattern (fieldset + legend + radiogroup + aria-invalid) scales naturally. ~5 days design.
• Lead Engineer: High. Group draw algorithm + recompute on disqualification + Pre-round bracket variation requires careful state-machine design. @g-loot/react-tournament-brackets supports groups + knockout natively; backend draw logic is the heavy lift. ~3-4 weeks engineering for full Groups+KO + Direct Advance + MGG.
• Security: Medium. New tournament_format enum + mgg_enabled + direct_advance_enabled columns + RLS check that organizer owns the tournament. Standard pattern.

Feature flag: tps-openrally-groups-plus-ko (PostHog). Roll out behind flag to internal organizers first, then 5% → 25% → 50% → 100% over 2 weeks.

Success metric: ≥30% of new tournaments choose Groups+KO over single-elim within 30 days of full rollout.

Rollout sequence (suggested v0.6 waves):

• W1-W4: Backend draw algorithm + groups table + group-membership rows
• W5-W8: UI for organizer-create (structure selection, group count, Top-N picker)
• W9-W12: Public bracket UI updates to show group-stage standings + KO bracket
• W13: MGG + Direct Advance toggles (gated to eligible team counts)

Delta D2 — WhatsApp / LINE deep-link templating, locale-aware, in v0.6

Current plan says: DECISIONS.md mentions Email (Resend SDK in openrally-backend) as primary channel. No messenger / WhatsApp / LINE strategy is documented.

Propose: In v0.6 add a messenger-deep-link templating system in openrally-backend Edge Functions: - Per-locale messenger preference (th → LINE primary, en-MENA → WhatsApp primary, en-SG → WhatsApp + LINE both) - Per-context deep-link templates (Solo registrants → Add partner / Manage; LFP → Manage listing; Waitlist → Position; Match day → Schedule) - Render in registration-confirmation emails as click-to-message buttons - "Send to LINE / WhatsApp" share buttons on tournament + player profile pages

Rationale (wecourts evidence):

• WeCourts shipped context-aware WhatsApp CTAs 2026-04-30 (raw-html/34-featurebase-changelog.text.txt Apr 30: "Better WhatsApp message links")
• Every wecourts club page has explicit "WhatsApp / Call Now / Send to WhatsApp / Copy Number" Quick Actions (raw-html/20-club-detail.text.txt)
• WhatsApp is the de-facto contact channel in MENA — every Jordan / UAE tournament's About text in our walk routes to WhatsApp
• For Thailand: LINE has ~50M users out of 70M population (LINE penetration is the highest in the world). For Indonesia / Vietnam / Singapore: WhatsApp dominant

Feasibility flags:

• Designer: Low. Adding messenger-share buttons + click-to-chat. ~2 days design.
• Lead Engineer: Low-Medium. Edge Function for templating; localized deep-link URL builder; UI buttons. ~5 days eng including tests.
• Security: Low. No new PII surfaces beyond what Tournament/Player already store. Phone number masking pattern already in plan (mirror wecourts's "last 4 digits visible" approach).

Feature flag: tps-openrally-messenger-deep-links (PostHog). Internal test → 5% → 100% in 1 week (low risk).

Success metric: ≥40% of post-registration emails get clicked-through on messenger CTA within 30 days.

Delta D3 — Looking-for-Partner (LFP) listings with structured padel meta in v0.6

Current plan says: DECISIONS.md §v0.4 partner registration covers W35 partner-search-modal (lookup by name) and W37 invite respond-form. No public LFP listing for unmatched solo players.

Propose: In v0.6 add LFP as a first-class concept: - New lfp_listings table (per Tournament, per Player, status open / connected / withdrawn) - Public LFP feed on tournament detail page (rating, hand, side, EXP visible; mobile masked until login) - "+N looking for partner" chip on tournament cards in tournament-list views - "Manage your listing" CTA in WhatsApp / LINE deep links per Delta D2

Plus: extend Player schema to capture playing_hand (R/L), preferred_side (R/L/Both), experience_years. These are padel-domain fields, not generic-sport fields — they directly determine partner compatibility. Without them, our LFP signal is weaker than wecourts's.

Rationale (wecourts evidence):

• LFP cards visible on raw-html/43-may-grand-clash.text.txt — 5 players in queue with structured WPPR ID, rating, hand, side, EXP fields
• "Looking-for-Partner spotlight" tournament card chip shipped 2026-04-30 (raw-html/34-featurebase-changelog.text.txt Apr 30)
• Featurebase top-rated complaint themes do NOT include "LFP is broken" → suggests this is a successful feature
• WeCourts's Hand + Side + EXP fields are padel-specific (tennis doesn't have left/right side preference). Padel community will expect this; if we ship LFP without it, ours feels generic.

Feasibility flags:

• Designer: Low-Medium. LFP feed card + tournament-card chip + Player profile extension. ~4 days design.
• Lead Engineer: Low-Medium. New table + RLS + 3 new player columns + UI. ~6 days eng including tests.
• Security: Medium. Mobile-mask pattern needed; RLS gates LFP feed to authenticated users for full reveal, anonymous gets rating + ID only. Mirror v0.4 W37 invite respond-form's mobile-mask pattern (already in DECISIONS.md).

Feature flag: tps-openrally-lfp (PostHog). 5% → 25% → 100% over 10 days.

Success metric: ≥15% of solo registrations convert to LFP listings; ≥30% of LFP listings result in a partner pairing within 7 days.

Delta D4 — Multi-currency on Tournament from v0.6 (was: implicit THB-only)

Current plan says: DECISIONS.md is silent on currency. "Thailand-first" branding implies THB.

Propose: Add entry_fee_currency enum on Tournament. Default to club's country currency (Club.country.default_currency). Display formatter resolves to ISO 4217. Support THB, MYR, IDR, SGD, VND, PHP, AUD as the SEA-relevant set + USD as a global fallback.

Rationale (wecourts evidence):

• WeCourts displays AED for UAE tournaments and JOD for Jordan tournaments (raw-html/43-may-grand-clash.text.txt + raw-html/46-jordan-drawer.text.txt) — multi-currency is shipped at the data layer
• OpenRally's roadmap explicitly says "padel-only, Thailand-first" but the Asia-Pacific scope implies expansion to MY / ID / SG / VN within 18 months
• Adding multi-currency at v0.6 is cheaper than retrofitting at v1.0 when tournament fees + prize pools are in the wild

Feasibility flags:

• Designer: Low. Display formatter + organizer-form dropdown. ~1 day design.
• Lead Engineer: Low. Schema migration + Intl.NumberFormat for display. ~2 days eng.
• Security: Low. No new attack surface.

Feature flag: tps-openrally-multicurrency. Internal → 100% in 5 days (low risk).

Success metric: Zero forced-currency bugs reported when first non-THB organizer onboards.

Delta D5 — Tournament status state expansion + Awaiting-WPPR-Verification queue (deferred until v3 rating integration; flag in DECISIONS.md now)

Current plan says: DECISIONS.md §v0.4 W41 status_transition.tsx has Open Registration / Close Registration. No awaiting_verification / published / waived states.

Propose: Don't ship state expansion in v0.6 — but ADD a note to DECISIONS.md saying the schema should reserve tournament.verification_state enum space now for not_submitted / submitted_pending / published / waived so we don't have to ALTER ENUM later.

Rationale (wecourts evidence):

• WeCourts has 4 explicit verification-state tabs on raw-html/16-results-tracker.text.txt: Recently Published / In Review / Pending / Overdue
• WeCourts publishes Overdue Results publicly as an accountability moat (raw-html/04-organizers.text.txt "Organizers with Overdue Results")
• OpenRally's planned v3 external-rating integration will need this state machine; shipping it pre-baked is cheap. Retrofitting later breaks public tournament URLs.

Feasibility flags:

• Designer: N/A (no UI yet).
• Lead Engineer: Low. Schema reservation only; no UI in v0.6. ~1 day eng.
• Security: Low.

Feature flag: Not needed (schema-only reservation).

Success metric: N/A — verifies when v3 ratings integrate.

Delta D6 — Shareable rich-preview player profile URL in v0.6 (early-stage variant)

Current plan says: DECISIONS.md §v0.4 W29 has /[locale]/organizer/[slug] public profile. No player public profile.

Propose: Add /[locale]/p/{player_id} public player profile page with: - Basic stats (matches played, win rate, gold/silver medal counts where available) - Recent tournament participation (last 5 events with results) - OG meta tags + Vercel OG image generation for rich WhatsApp / LINE / X preview - Shareable button "Share Profile" → copies link to clipboard with locale-aware messenger picker

Until v3 rating integrates, the page shows no rating (or shows external rating if linked via OAuth to an existing FIP / WPPR / UTR account, but that's out-of-scope for v0.6).

Rationale (wecourts evidence):

• WeCourts shipped this 2026-03-13 ("Player Profiles — Completely Reimagined" — raw-html/34-featurebase-changelog.text.txt Mar 13)
• "Share Your Profile — generates a rich preview automatically — on WhatsApp, social, anywhere" — viral mechanic
• Currently the only "shareable URL" OpenRally will have at v0.6 is the tournament page (W33) — player profile would 5x the share surface

Feasibility flags:

• Designer: Low-Medium. Player profile page design + OG image template. ~4 days design.
• Lead Engineer: Low. New route + Vercel OG image generator + meta tags. ~3 days eng.
• Security: Medium. Public player page exposes name + city + match history. RLS on the underlying query must respect the player's privacy toggle. OpenRally's v0.4 W29 organizer-public-profile pattern (hidden contact section when not approved) is the right template.

Feature flag: tps-openrally-player-public-profile. 5% → 100% over 7 days.

Success metric: ≥10% of public-profile views originate from messenger-app referrers within 30 days.

Delta D7 — Multi-organizer collaboration (RBAC on a Tournament) in v0.7

Current plan says: DECISIONS.md §v0.3 W18 middleware gates by 'organizer' = ANY(roles) — single-organizer ownership of Tournament.

Propose: Land multi-organizer collaboration in v0.7 (after Groups+KO ships in v0.6): - New tournament_members table (organizer_id, role, granted_permissions) - Roles: owner / co-organizer / scorer / referee — 4 roles, smallest reasonable set - Invite-via-email + accept flow (mirroring v0.4 W37 invite/respond-form pattern) - Tournament edit / scoring / disqualification gated by role - Display "Co-organized by X, Y" on tournament public page if >1 collaborator

Rationale (wecourts evidence):

• WeCourts shipped "Collaboration Accounts" as a Completed feature on Featurebase (raw-html/32-featurebase.text.txt): "Let multiple organizers manage a single tournament together — shared access to draws, scoring, and settings without needing to share one login."
• WeCourts's BPT / DSG / WPA tournaments visibly co-credit multiple organizers (raw-html/13-sample-event.text.txt shows "BY {organizer-brand}" and "MD {assistant-name}" — implies a 2-person model already)
• Real-world organizer workflow: tournament director + scorers + referees + commercial partner — they currently share one login (a security anti-pattern) or chain WhatsApp screenshots

Feasibility flags:

• Designer: Medium. Invite-flow + role-permission table + organizer-list display on tournament page. ~6 days design.
• Lead Engineer: Medium-High. RLS rewrite for tournament_members table + role-permission matrix + invite flow + audit trail. ~3 weeks eng.
• Security: High. This is the biggest security review surface in this proposal. Role-permission matrix has to be airtight (a co-organizer must NOT be able to disqualify the owner; a scorer must NOT be able to delete the tournament). RBAC tests + threat-model session needed.

Feature flag: tps-openrally-collab. Designer + Lead Engineer + Security review before ANY rollout; then internal → 5% → 25% → 100% over 4 weeks with metric-watch.

Success metric: ≥20% of organizer accounts have ≥2 collaborators on at least one tournament within 60 days.

Risks + What I'm Not Sure About

R1. WeCourts could ship in SEA before our v1.0

Their iOS listing explicitly says "More countries soon!" If they target Indonesia (Muslim-majority, padel-growing) or Singapore (English-speaking, high padel-club density) before our v1, our i18n + local-relationships moat shrinks. What we don't know: their next-country roadmap is not on Featurebase publicly.

Mitigation: Lock SEA federation / association partnerships in v0.6 timeframe. Get exclusivity language where possible — even informal "we'll launch with you" agreements buy time.

R2. The "AI poster upload" claim might be vaporware

I've only seen the marketing copy, never tested it. If it works well, it's a real differentiator (organizers prefer 1-tap to a 20-field form). If it's regex + OCR with 60% accuracy, it's marketing noise.

Mitigation: Test it the moment Nestor unblocks. If it works, ship our cleaner Claude Vision version in v0.7. If it doesn't, no urgent action.

R3. Multi-organizer RBAC has the highest security review surface

A bad role-permission table = a co-organizer can grief the owner. Worse: a scorer can manipulate match scores after submission. We have to invest in this.

Mitigation: Designate Security Engineer to own the threat model. Add audit-log table for every collaborative action (who edited what when). Don't ship without a documented permission matrix in DECISIONS.md.

R4. Bracket-format breadth (D1) is a 3-4 week eng investment

Groups+KO + Direct Advance + MGG is substantial. We may underestimate the state-machine complexity. WeCourts presumably went through 2-3 iterations before shipping cleanly.

Mitigation: Spike the draw algorithm in week 1 of v0.6 development; gate the v0.6 ship on that spike passing.

R5. The v1 non-goal "no rating algorithm" may be wrong

DECISIONS.md says "v3 integrates external" — but external integration is also slow (FIP, UTR, WPPR, federation APIs are all guarded). If we're forced to integrate FIP and FIP charges a fee or rate-limits us, that's a problem.

Mitigation: Open a side-conversation about a OpenRally-controlled rating mechanism (even a confidence-weighted Elo) as a fallback. Don't commit, but don't close the door.

R6. "Trust-as-product" is a marketing slogan unless we deliver

Saying we have cleaner identity than wecourts requires shipping merge-tools, name-canonicalization, audit-trail, abuse-reporting from day 1. If we ship a quick MVP and skimp on identity hygiene, we get the same Featurebase pain wecourts has.

Mitigation: Add identity-hygiene acceptance criteria to every OpenRally PR that touches player records. Mirror wecourts's Apr 30 validation rules (reject test/tbd/asdf, partner-≠-self, phone normalization).

R7. WeCourts is on Featurebase + we recommend Featurebase — vendor risk

If wecourts is a flagship customer, Featurebase might give them better support / earlier features than us. Choosing the same vendor stack as a competitor isn't a strategic loss but it's not a moat either.

Mitigation: Either pick a different feedback tool (Productboard, Canny, Notion public) OR pick Featurebase and treat the public-roadmap as parity hygiene, not advantage. My recommendation: Notion public for now (already in OpenRally's stack), Featurebase later.

R8. We don't know wecourts's WPPR-Partner pricing

Their footer "Become Partner" → WhatsApp implies a sales-led pricing model. We don't know the dollar amount. This matters because if it's $500/mo per partner, that's their revenue. If it's $10k/yr, that's another. What we don't know: the actual partnership-tier pricing.

Mitigation: Out-of-scope for read-only intel. If material to OpenRally pricing decisions, the right next step is reaching out as a hypothetical buyer.

Decision Asks for Nestor

Each is yes/no-answerable. Sorted by strategic weight — answer 1-3 first; they set the frame for the others.

Strategic (answer first)

1. D1 — Posture vs wecourts: Are we publicly positioning as the SEA-padel-platform that wecourts isn't (shaping marketing, partnerships, and roadmap urgency around being-not-them), or keeping the competitive lens internal-only? Public narrative / Internal-only / Hybrid
2. D2 — Bracket-format breadth in v0.6: Do we ship Groups+KO with Direct Advance + MGG in v0.6 (~3-4 weeks eng — see Delta D1)? Yes / No / Defer to v0.7
3. D3 — "No OpenRally rating algorithm" v1 non-goal: Do we leave this hard fence in place through v2 or open it for review at next quarterly planning? Relying on external (FIP / UTR / WPPR / federation) is also a fragility. Leave in place / Open for review / Decide later

Tactical (answer once strategic frame is set)

4. D4 — WhatsApp + LINE deep-link templating in v0.6 (Delta D2, ~5 days eng): Yes / No
5. D5 — LFP listings + 3 new Player columns (Hand/Side/EXP) in v0.6 (Delta D3, ~6 days eng): Yes / No
6. D6 — Shareable rich-preview player profile URLs in v0.6 (Delta D6, ~3 days eng): Yes / No
7. D7 — Multi-currency on Tournament in v0.6 (Delta D4, ~2 days eng): Yes / No (THB-only fine for now)
8. D8 — Multi-organizer RBAC in v0.7 (Delta D7, ~3 weeks eng + high security review): Yes / No / Defer to v0.8
9. D9 — Public roadmap (Featurebase / Notion public / internal-only / none) at v1.0 ship: Yes via Featurebase / Yes via Notion public / Yes via internal-only / No

What I'm not asking you to decide today

Items deliberately punted:

• TV / venue-display product — needs revenue case (paid venue licensing? free with WeCourts-style branding?). Schedule a separate conversation in Q3 planning.
• AI poster-to-form — gated by my hands-on test of wecourts's version once unblocked. Will recommend after that.
• Public Developer API — needs sizing of revenue potential; out of scope for this round.
• Federation partnerships (TLPA / national bodies) — partnerships strategy belongs to GTM / BD discussion, not product.
• Payments timing (currently v5 in DECISIONS.md) — depends on Decision 1's posture. If we go publicly competitive with wecourts, we may need payments at v3-v4 instead of v5. Bring this back at the next quarterly planning.

Acceptance criteria for this proposal

If Nestor approves the deltas, the following must happen before any code merges:

• AC-1: DECISIONS.md updated with new entries for D1-D7 (whichever are approved), each with rollout flag name, owner, target version, success metric.
• AC-2: Each approved delta gets a Linear ticket (TPS-XXX style, or openrally equivalent) with the acceptance criteria from this proposal verbatim.
• AC-3: Designer reviews D1, D3, D6, D7 UX feasibility (the four that have meaningful UI surface).
• AC-4: Lead Engineer + Security Engineer review D7 (multi-organizer RBAC) before any branch opens — pre-implementation threat-model.
• AC-5: PostHog feature-flag names registered (tps-openrally-groups-plus-ko, tps-openrally-messenger-deep-links, tps-openrally-lfp, tps-openrally-multicurrency, tps-openrally-player-public-profile, tps-openrally-collab).
• AC-6: Self-critique loop: this proposal gets re-read against product-hub/competitors/wecourts/self-critique.md to confirm no Tier-3 weakness re-emerged.

Source evidence map (every claim in this proposal points to one of these)

Post-onboarding-walk addendum (2026-05-22)

Nestor unblocked the email-verification gate with code 157208. The agent walked signup → /onboarding → /onboarding/pending-review but hit a SECOND gate: manual organizer approval via WhatsApp ("usually within a few hours" SLA). The wizard-walk for /tournaments/new remains gated.

That said, the partial Phase 3 walk produced substantial new evidence that changes some deltas and adds new ones below. See self-critique.md "Post-gated-walk revisions" for the audit trail.

Changes to existing deltas

D1 (Groups+KO in v0.6) — STANDS but with slightly tighter timing argument. Risk R1 (wecourts could ship in SEA before our v1.0) moved from "12-24mo" to "6-12mo" because the onboarding country dropdown is full ISO-3166 — they're a flag-flip from launching SEA. Decision-ask urgency increases.

D2 (WhatsApp + LINE deep-link templating in v0.6) — STRENGTHENS. Phase 3 confirmed wecourts uses WhatsApp not just for player UX but for internal ops including the organizer-approval notification moment. This makes the messenger-native strategy more important, not less. Recommend bumping to top of v0.6 priority list.

D3 (LFP with structured padel meta in v0.6) — STANDS. No new evidence either way.

D4 (Multi-currency in v0.6) — STRENGTHENS. Country dropdown observed in onboarding is full ISO-3166 — implies wecourts schema already handles multi-currency wherever Tournament rows exist. Mirror or be left behind.

D5 (Tournament verification-state schema reservation) — STANDS.

D6 (Shareable player profile rich-preview URL in v0.6) — STANDS.

D7 (Multi-organizer RBAC in v0.7) — STANDS but might want to land sooner since the manual-approval moat suggests wecourts isn't currently scaling collaboration to multiple users easily; an organizer team feature is real differentiation.

NEW deltas added by Phase 3 evidence

Delta D8 — Self-serve organizer onboarding (no manual gate) with strong abuse-controls (v0.6)

Current plan says: DECISIONS.md §v0.3 W20-W21 ships an admin Approve/Reject flow for organizer_application rows. The wave-25 W25 onwards organizer surface implies approved organizers reach the dashboard, but the exact hard-gate-vs-soft-gate behavior isn't specified.

Propose: Ship self-serve organizer onboarding in v0.6 — approved-by-default with the following abuse-controls: - Mobile OTP verification on signup (mandatory) - Country + city dropdowns (cascading) with country defaulting to user's IP geo - Dedupe-search-before-create pattern: show existing organizers in the user's country/city before allowing them to create one - "Reputation" trust tier: new organizers start at unverified (can create tournaments but tagged "Unverified Organizer" publicly until 1st tournament completes with results submitted on time) - Automatic spam detection: name validation (reject test/tbd/asdf, per wecourts's Apr 30 changelog rules) + duplicate-name guard - Featured / WPPR-equivalent tier remains sales-qualified (openrally-side: a "Verified Partner" badge) just like wecourts's WPPR Partners

Rationale (wecourts evidence):

• WeCourts's manual review is a moat AND a scaling bottleneck — they cap at ~92 organizers because they review every one (raw-html/04-organizers.text.txt). OpenRally gains by removing the bottleneck.
• WeCourts's pending-review UX (screenshots/51-onboarding-pending.png) is a friction point: "usually a few hours" SLA means motivated organizers may bounce.
• OpenRally's v0.3 W20-W21 already has the admin Approve/Reject infrastructure — the question is whether to make it MANDATORY or OPTIONAL (soft).
• Self-serve + reputation tier is the modern SaaS path; manual-review is the marketplace-trust path. With strong abuse-controls (mobile OTP + dedupe + name validation + first-tournament reputation gate), self-serve gets ~90% of the trust outcome at ~10% of the operational overhead.

Feasibility flags:

• Designer: Medium. Onboarding wizard with dedupe-search + reputation badging on tournament cards. ~5 days design.
• Lead Engineer: Medium. State machine + reputation table + abuse-control rules engine. ~2 weeks eng.
• Security: Medium-High. Abuse-control rules need to be tuned (false positive vs false negative). Need a reporting/escalation path for organizers flagged by automation.

Feature flag: tps-openrally-self-serve-organizer. Internal test → 25% → 100% over 2 weeks. Existing organizer_application Approve/Reject UI stays for the manual override path.

Success metric: ≥80% of new organizer signups create their first tournament within 24 hours of signup (vs wecourts's "a few hours" gate floor).

Delta D9 — Two-persona organizer model (Padel Club vs Organizer Company) in v0.7

Current plan says: DECISIONS.md treats Organizer as a single concept. The v0.3 W25-W31 organizer surface assumes a 1:1 organizer-to-club model.

Propose: In v0.7, after self-serve onboarding (D8) lands, fork the organizer model into two persona types: - Padel Club — venue-anchored, single physical location, default operator (club staff) - Organizer Company — multi-venue, runs tournaments at multiple clubs, may have NO physical venue of their own (e.g., a tournament-management company that rents courts)

Schema: Organizer.organizer_type enum (padel_club / organizer_company). Different forms / different downstream UX.

Rationale (wecourts evidence):

• WeCourts's onboarding (screenshots/52-onboarding-root.png) explicitly asks "How do you run tournaments?" with these two cards
• The downstream Club-create form (screenshots/60-onboarding-create-club.png) vs Company-create form (screenshots/64-create-company-form.png) have different required fields
• Real-world organizer types in SEA mirror this split: padel clubs (e.g., a Bangkok-based club hosting weekly socials) vs event-management companies (e.g., a touring league like Padel Sphere that runs events at multiple venues)
• OpenRally's current single-organizer model will hit friction when a multi-venue tour wants to sign up

Feasibility flags:

• Designer: Low-Medium. Persona-choice screen + two forms. ~3 days design.
• Lead Engineer: Low-Medium. Schema discriminator + form branching + small admin UI extension. ~5 days eng.
• Security: Low. No new attack surface.

Feature flag: tps-openrally-organizer-personas. 5% → 100% over 7 days.

Success metric: ≥20% of organizers self-identify as organizer_company (validating the persona is real).

Delta D10 — Federation partnership framework (BD + product, lined up for v3-v4)

Current plan says: DECISIONS.md is silent on federation partnerships. The "TLPA partnership" is in the proposal's "What I'm not asking you to decide today" list as a GTM concern.

Propose: Promote federation partnerships from GTM-only to a joint Product + BD initiative with concrete deliverables by v1.0: - BD: Approach TLPA (Thai Lawn Tennis & Padel Association) + Malaysian / Singaporean / Indonesian / Vietnamese equivalents with a "OpenRally is the official tournament-ops platform for {federation} tournaments" pitch - Product: Reserve schema room for Federation entity (parent of multiple Organizers, can set policy / templates / mandatory acceptance criteria for member-organized tournaments) - Marketing: Add "Official Federation Partner" badge to Tournament + Organizer pages — visible trust signal

Rationale (wecourts evidence):

• WeCourts's redesigned WPPR page (raw-html/67-rating-wppr.text.txt) prominently displays "OFFICIAL RATING PARTNER FOR: Egypt Padel Federation, Jordan Tennis Federation"
• WeCourts's /organizers page (raw-html/04-organizers.text.txt) lists Jordan Tennis Federation, UAEPA, Pakistan Padel Federation as organizers — they've already onboarded federations
• Federation partnerships compound: a federation endorsement legitimizes the platform to clubs, which legitimizes it to players. Compound effect on the identity-graph moat.
• OpenRally's window to lock SEA federations is closing as wecourts expands

Feasibility flags:

• Designer: Low. Add "Official Federation Partner" badge component. ~1 day design.
• Lead Engineer: Low-Medium. Schema add for Federation entity + member-organizer FK + badge rendering. ~5 days eng.
• Security: Low.
• BD/GTM: HIGH — this is primarily a relationships play. Product is the enabler. Designate a BD owner.

Feature flag: N/A (BD-led).

Success metric: ≥1 SEA federation partnership announced by v1.0 ship; ≥2 by v2.0.

Delta D11 — Dedupe-search-before-create pattern for ALL entities (player + club + organizer) in v0.6

Current plan says: DECISIONS.md doesn't specify dedupe-search behavior on entity creation. OpenRally's v0.3 W20-W21 organizer-application flow doesn't show applicants existing organizer rows before they create a new one.

Propose: Adopt the dedupe-search-then-create pattern uniformly: - On organizer signup: "Find your organizer" → existing matches → "Create new" fallback - On club / venue creation: "Find your club" → existing matches → "Create new" fallback - On player registration to a tournament (CRITICAL — this is where wecourts's identity graph leaks): "We found a similar player — is this you?" before allowing a new player record to be created

Rationale (wecourts evidence):

• WeCourts gets dedupe right on Organizer + Club paths (screenshots/53, 59 — search-list-then-create)
• WeCourts gets dedupe WRONG on Player path — Featurebase complaints (Jiten, Elie Nasr) about duplicate profiles + no merge UI
• OpenRally's v0.6 LFP + identity-graph foundation is the right moment to bake this in across all entity types

Feasibility flags:

• Designer: Low. "Find your X" component + fuzzy-match list. ~2 days design.
• Lead Engineer: Low-Medium. Server-side fuzzy-match endpoint + component integration. ~4 days eng.
• Security: Medium. Fuzzy match must not LEAK personal data on partial matches (e.g., don't reveal full phone numbers in search results). Mirror wecourts's "last 4 digits masked" approach.

Feature flag: tps-openrally-dedupe-search. 100% from launch (low-risk default).

Success metric: Duplicate-record creation rate < 2% within 90 days post-launch (vs wecourts's visible 5-10%+).

Delta D12 — Identity-graph foundation (player canonical identity) in v0.7

Current plan says: DECISIONS.md says "No OpenRally-built rating algorithm (v3 integrates external)." The Player canonical-identity question (one user → one profile, cross-tournament) is NOT directly addressed.

Propose: In v0.7 (after self-serve organizer onboarding D8 lands), build the player identity foundation WITHOUT the rating algorithm: - Canonical Player table with player_id (UUID), mobile OTP-verified phone, email, name - Player records can exist before signup (created by organizers submitting results) BUT must be claimed via mobile OTP before any rating can be associated - "Claim your profile" CTA on Player rows that lack a claim - Merge UI: if a player finds duplicate records of themselves, they can self-serve merge (with confirmation flow) - Audit log of every merge / claim event

Rationale (wecourts evidence):

• WeCourts's identity-graph IS the moat — proven by the phone-auto-resolve we observed (screenshots/52 "WhatsApp verified" without entering a phone)
• WeCourts's identity-graph is ALSO their biggest pain (Featurebase complaints about duplicates + missing merge UI)
• OpenRally cannot win on the rating side without canonical player identity (the rating, whoever computes it, must be attached to a stable identity)
• Building identity-graph in v0.7 — BEFORE v3 rating integration — means when external rating lands, we already have clean identities to attach ratings to

Feasibility flags:

• Designer: Medium. Claim CTA + merge UI + audit-log surface. ~5 days design.
• Lead Engineer: Medium-High. Mobile OTP infrastructure (Supabase Auth has phone-OTP), canonical identity table, merge transaction (atomic, reversible), audit log. ~3 weeks eng.
• Security: HIGH. Phone-OTP infra has fraud/abuse surface; merge transactions need to be reversible and audit-trail-locked; canonical identity may have PII implications.

Feature flag: tps-openrally-identity-foundation. Internal → 5% → 100% over 4 weeks.

Success metric: ≥95% of new player records have a claimed mobile within 30 days of creation. Duplicate-record merge requests resolve in < 24hrs self-serve.

Updated decision asks (Phase 3 addendum)

Adding 3 new decision asks to the existing list:

10. D10 — Self-serve organizer onboarding vs manual approval gate: Self-serve with abuse-controls (Delta D8) / Manual review like wecourts / Hybrid
11. D11 — Two-persona organizer model (Padel Club vs Organizer Company) in v0.7: Yes / No / Defer to v0.8
12. D12 — Federation partnership framework (Delta D10) — promote from BD-only to joint BD+Product: Yes / No / Defer to v1.0 planning

Decision 12 also implicitly answers a partial question raised earlier (the "Federation partnerships (TLPA / national bodies)" item in "What I'm not asking you to decide today" list).

Implications for ORIGINAL decision asks

• D1 (posture vs wecourts): Even more critical now. The Phase 3 walk confirms wecourts is faster than I estimated (full ISO-3166 country support already in onboarding flow). The window to define our public posture before they show up in SEA is shorter. Recommend deciding Decision 1 within 2 weeks.
• D3 ("no OpenRally rating algorithm" v1 non-goal): Strongest case yet for revisiting. The redesigned WPPR page positions wecourts as a data-aggregation hub (FIP, Premier Padel, RankedIn, Winner App, Tournify, AI cameras, Excel sheets, whiteboard photos). If we stay 100% external-dependent, we're a feature of THEIR hub. If we build an Elo-or-Glicko-style rating ourselves AS A FALLBACK while still integrating external where available, we're not at their mercy.
• D4-9: Tactical decisions stand as-is.

Source evidence map (Phase 3 additions)