Every requirement on record, and exactly where it is. Updated as we build.
Done = built, tested & usable · Prototype = clickable demo, not final · Building = in progress now · Planned = on the list.
⛓ Needs first shows what a feature depends on. Chips are colored by status — green = already built, amber = prototype, red = still to build. A row with a red chip is waiting on something else first. Example: the per-event features (count, waiting list, caps) all need F-61 (events as a real thing).
| tool | Done | Brain-dump intake page (the tool you’re using) Live & in use. |
| tool | Done | Photo / screenshot upload on the brain-dump page Attach up to 3 images; safety-checked. |
| F-01 | Done | Player registration (name, address, phone, email) OPERATIONAL — the Register page saves real players to the server (validated server-side), and they appear live on the Roster (name, flag, rating; contact details are shown to the TD only). Covered by automated tests. Storage resets on redeploy until a permanent database is wired (same as the brain-dump page). (open →) |
| F-02 | Done | Phone-number validation at sign-up OPERATIONAL — validated on the form AND on the server (rejects bad numbers, normalizes to (555) 123-4567). Covered by automated tests. (open →) |
| F-03 | Prototype | Payment (Venmo / PayPal) + paid status per entrant WORKING sandbox flow, run by the TD: on any event with an entry fee, the signed-in TD taps Pay on a pending entry → provider-style checkout → a captured payment AUTO-SEATS them, with a confirmation page (F-56). The sandbox is TD-only so nobody can take a seat without paying; players pay the TD at the door until live payments exist. Money core is a real Stripe/PayPal state machine — idempotent, refund-drops-the-seat, webhook signature-verified (automated tests). Runs in SANDBOX (no real money) until live keys + the merchant-of-record decision (your + Ryan go-ahead). (see the demo →) |
| F-04 | Prototype | QR-code sign-up (scan to register & pay) QR card shown on the registration page; real scan-to-pay rides on the payment backend. (see the demo →) |
| F-05 | Prototype | Auto-build bracket — DOUBLE elimination with byes Operational draw at /draw — takes the REAL players on your Roster and draws them into a double-elim bracket: correct bracket size and the right number of byes for an uneven field (48 players → 64 slots, 16 byes), spread across the bracket. Default is UNSEEDED (Jon usually just starts a bracket without seeding, so byes fall on random players, NOT the top seeds); seeding by FargoRate is an option. Tap any rating to see it’s locked (F-54). NEW: the full double-elimination STRUCTURE is now computed and shown from your field — winners rounds, the losers’ bracket (correct 2(k-1)-round shape, size-2 matches), and the grand final, with the match totals (e.g. 64 slots → 63 winners + 62 losers + 1 GF). Tested (10 draw tests incl. the double-elim match-count invariants). Next rung: the match-by-match loser DROP routing — which specific losers’ round each winners’ loser falls into. ✅ Needs (all built): F-01 (see the demo →) |
| F-06 | Prototype | Match-time estimates On the table-management prototype — average match length + estimated round finish. (see the demo →) |
| F-07 | Prototype | “You’re up” text-message alerts Prototype at /texts — composes the alert. Sending a REAL text needs a paid texting service (your go-ahead). (see the demo →) |
| F-08 | Prototype | Big-screen display, searchable by player name Demo at /bracket — being upgraded to a double-elim view. |
| F-09 | Planned | Other formats — single-elim, round robin, Swiss Secondary to double-elim. |
| F-10 | Prototype | Team / doubles events Scotch Doubles, Jack N Jill, Pick Your Own. PROTOTYPE LIVE (2026-10-20, Annabel): set an event’s FORMAT to Doubles in setup (the /events create form) and give it a COMBINED team cap — e.g. 1300. An entry is then a TEAM of two: both partners’ names are required, their FargoRates are ADDED, and a pair whose combined rating is over the cap is turned away at entry with the reason (“team combined 1420 is over the 1300 cap”). The event page shows each team as a pair with their total handicap (e.g. “Annabel 405 + Jon 689 = 1094”), and the field cap / waiting list / count all count TEAMS (one team = one seat). An unknown rating can’t be summed, so it passes for the TD to resolve. The bracket draws teams seeded by their combined handicap. Covered by tests. The combined cap is set in event SETUP (Annabel: “should be part of setup”). Still to come: other team formats (Jack N Jill pairing rules, Pick Your Own) and per-partner rating lock at payment (F-52). Builds on F-61 (events) + F-23 (the singles cap it parallels). (see the demo →) |
| F-11 | Prototype | Game type per event (8/9/10-ball, one-pocket…) Game-type picker on the venues/series prototype (and in setup). (see the demo →) |
| F-12 | Prototype | “Added money” — pool hall adds to the pot On the payments prototype and wired live into the payout calculator (F-19). (see the demo →) |
| F-13 | Prototype | Venues / pool halls Prototype at /venues — venue cards + add-a-venue form. (see the demo →) |
| F-14 | Prototype | Player profiles + ratings Click any player on the Stats page to open their card — FargoRate skill level, Fargo ID, matches played, match-history chips, effective rating with the +/- change. Our own look. (see the demo →) |
| F-15 | Prototype | Live table management (assignments, on-deck, times) Prototype at /tables — 6 live table cards with running timers + an on-deck queue you assign from. (see the demo →) |
| F-16 | Prototype | Stream overlay + public spectator page Prototype at /spectator — public live view + a broadcast lower-third overlay for the stream. (see the demo →) |
| F-17 | Prototype | FargoRate reporting / export On the TD/Admin prototype — results table with a working CSV export. A direct FargoRate tie-in is a later rung. (see the demo →) |
| F-18 | Prototype | Calcutta (optional auction side-pot) Toggle-on auction on the payments prototype — bids + running Calcutta pool. (see the demo →) |
| F-19 | Prototype | Payout calculator (entry fees + added money → payouts by place) Live & operational at /payout — real tested engine. Jon’s two rules are enforced in the math: pay the top 25% of the field, and the lowest paid spot ALWAYS gets at least the entry fee back (so a $40 entry never pays under $40). The split flattens as the field grows, added money goes in the pot, whole-dollar amounts, ties paid equally (5-6 / 7-8 / 9-12). Change any number and it recomputes. Tuning the exact top-heaviness is the only thing left. ⛓ Needs first: F-22 (see the demo →) |
| F-20 | Prototype | Secure TD / Admin page (login-protected & locked) TD sign-in is REAL on the server now (beta: one shared TD password from the key vault, Annabel 2026-10-23): /admin, /tracking, creating events, dropping entries, marking paid and the brain-dump tool all ask for it; /td/sign-out forgets it on a shared tablet. The /admin dashboard itself is still a prototype. Per-TD accounts are the “done” step. (see the demo →) |
| F-21 | Planned | Flyer upload per event Jon’s request — attach an event flyer to each tournament. |
| F-22 | Prototype | Event setup — entry fee, added money, green fees, ruleset, game type, race-by-entries, reg cutoff Walk-through prototype at /setup — 8 steps, our own style. Fields read off the real Fargo Billiards flyer. Confirmed: create event, flyer, details+rules, pick table numbers. (see the demo →) |
| F-23 | Prototype | Rating caps & eligibility (“X & Under”; min Fargo games or TD-approved) e.g. “505 & Under”, “500 games in FargoRate or TD approved”. SCOPE (Annabel, 2026-10-20): the cap is an EVENT rule, not a player property — it only comes into play when a player tries to ENTER a tournament that has a published cap. At that moment, if their rating is over the cap, THEY get turned away. The master Roster is just the player directory (everyone — including 600+ players who’d never enter a 505), so it must NOT show a cap flag (that preview was removed). PROTOTYPE LIVE (2026-10-20): now enforced AT ENTRY — on an event with a rating cap (F-61 /events), adding an entry whose rating is over the cap is rejected with the reason (“over the 505 cap, rated 540”); an at-the-cap rating is eligible; an unknown rating passes for the TD to resolve. Proven live: Jon Brown (689) is correctly turned away from a 505 & Under. Min-games / TD-approval override is partly done (under-500-games players already flag “needs TD approval”). Still to come: judge against the LOCKED rating once payment (F-52) pulls+freezes it; the cutoff (F-22). Builds on F-61 (events) + F-52 (lock). (see the demo →) |
| F-24 | Prototype | Tournament series / schedule (recurring events across a season) Prototype at /venues — a season schedule (Nov 2025–May 2027) with add-an-event. Jon runs a monthly series; each event gets its own flyer & setup. (see the demo →) |
| F-25 | Prototype | Show each player’s FargoRate on the bracket (like DigitalPool) Now visible in the double-elim demo as an “FR” pill. |
| F-26 | Prototype | Player profiles — rating links + self-service edits The registration form doubles as the self-edit profile; FargoRate/CSR lookup is on it. (see the demo →) |
| F-27 | Prototype | Fees shown before payment + manual add + payment tracking On the payments prototype — fees shown before paying, mark-paid by hand, live collected total. ⛓ Needs first: F-03 (see the demo →) |
| F-28 | Prototype | Registration confirmations & director alerts Confirmation message composes on /texts and /register; real sending needs the paid texting service. (see the demo →) |
| F-29 | Prototype | Match texts with table # + scoring link On the scoring prototype (and /texts) — the “you’re up” text carries the table # + a scoring link. (see the demo →) |
| F-30 | Prototype | Player management — FargoRate & CSR lookup by name Look-up-by-name on the registration/add-players flow pulls FargoRate + games. (see the demo →) |
| F-31 | Prototype | Match scheduling — scheduled times or shotgun Scheduled-vs-shotgun toggle on the table-management prototype. (see the demo →) |
| F-32 | Prototype | Score approval — director-approved or automatic On the scoring prototype — toggle between TD-approval and auto-post. (see the demo →) |
| F-33 | Prototype | Scoring format — win/loss or points (configurable 10-point) On the scoring prototype — race (win/loss) or a 10-point format. (see the demo →) |
| F-34 | Prototype | Run tracking — table runs & break-and-runs On the scoring prototype — table-run and break-and-run counters. (see the demo →) |
| F-35 | Prototype | Statistics — records, rack results, points, run totals Live at /stats: a sortable player table (place, match record, match win %, game record, game win %) with click-through to each player’s card. Our own look, not a clone. (see the demo →) |
| F-36 | Prototype | Bracket view controls — fullscreen, zoom, print/export Live on the bracket demo: fullscreen for the TV, zoom in/out with a % readout, print / Save-as-PDF. Download-as-image is a later rung. (see the demo →) |
| F-37 | Prototype | Split-bracket format — two FargoRate-seeded brackets merging into one final Selectable in setup (Type). Bracket 1 = top 50% by FargoRate, Bracket 2 = bottom 50%; both double-elim; top finishers from each advance to a final (single or double); each bracket draws random or seeded. Advance-cut being confirmed. (see the demo →) |
| F-38 | Prototype | Multi-flight format — divide a big field into N brackets, top finishers into a final Selectable in setup (Type). e.g. 128 players → 4 × 32 double-elim brackets; the top 25% of each flight (8 of 32) are randomly drawn into a final 32-player double-elim. Or run as one single bracket. Flight count & flight assignment still to be dialed in. (see the demo →) |
| F-39 | Prototype | Text players their bracket link after the draw On the text center — a one-tap “bracket is set” message with each player’s bracket link. Real sending needs the paid texting service. ⛓ Needs first: F-05 (see the demo →) |
| F-40 | Prototype | Post payouts on the bracket Payout for each finish shown right on the bracket at the round it’s decided (e.g. “3rd ($310)”), like DigitalPool. Live on the demo; will pull real amounts from the payout calculator (F-19). (see the demo →) |
| F-41 | Prototype | Live match tracker — whole-event match history with durations + slow-player flags Live at /matches: every match in the event in real time (players, score, table, ID, progress, status) with how long each one took. Long matches get flagged and a “slowest players” table ranks who’s taking the most time per match — so the TD can keep the room moving. In-progress matches tick up live. (see the demo →) |
| F-42 | Prototype | Eligibility rule — minimum FargoRate games to register (e.g. 500), or TD approval Tournaments can require a minimum number of FargoRate games played (the 505 used 500) or TD approval to enter. On the Stats page, any player under the threshold who isn’t TD-approved has their rating shown in RED with a “⚠ games” flag so the TD spots them at a glance; TD-approved players under the line show a green “TD OK”. The threshold will be set in event setup; approval will live behind the secure TD view (F-20). (see the demo →) |
| F-43 | Prototype | Bracket theme — dark mode + customizable colors The 🎨 button on the bracket opens a theme panel: presets (Blue felt, Dark mode, Green felt, Maroon), a dark-mode toggle, and individual color pickers for a two-tone background (top + bottom tone), player names, ratings, winner/advancing, table assignment, lines/borders, and accent. Saved per device. Our own look end-to-end — the competitor screenshots guide which options to offer, never how it looks. (see the demo →) |
| F-44 | Prototype | Country flag by each player’s name The FULL flag (not a small cropped icon like DigitalPool) shown next to each player’s name. Picked at sign-up — OR auto-set from the address they enter (type your address → the right flag appears). Live on the bracket, Stats page + player card, and the Add Players step. Production will use full rectangular flag images so they stay crisp and render on every device. (see the demo →) |
| F-45 | Prototype | Add Players — type a name, auto-fill from their account In setup Step 3, the TD starts typing a player’s name and — if that player has an account — their FargoRate, games played, phone, email, and flag fill in automatically. No account found → add them as a guest, flagged for TD approval (eligibility). Flyer upload also moved up into Step 1 (create the event). (see the demo →) |
| F-46 | Prototype | Live match clocks + loser routing + race-to on the bracket On the bracket itself: each match shows its start time and a live running clock for the match in progress; each winners-side match shows where the loser drops to on the losers side (e.g. “Loser → L3 · Losers R2”); and each player shows the number they race to next to their rating, e.g. “541 (6)”. (see the demo →) |
| F-47 | Prototype | ★ WOW — Self-running broadcast TV board LIVE PROTOTYPE at /live — the thing that makes us NOT a DigitalPool reskin. Instead of a ladder, it’s an ESPN-style big-screen board you cast to the bar TVs: the match ON NOW huge and center-stage with score bars, an UP NEXT ticker scrolling the on-deck matches, an ⚡ UPSET WATCH callout when a lower rating is beating a higher one, and the title favorites. Reads the REAL roster/field. REAL-WORLD FIT (Annabel): Amanda already HDMIs her Mac to a big TV to show the DigitalPool bracket — BUT that TV is NOT touchscreen and players kept poking it to jump to themselves. So this board is SELF-RUNNING: it auto-cycles through the matches with no interaction needed (Amanda casts it and walks away), and “find yourself” is pushed to each person’s PHONE via the spectator page (F-16) — hands off the shared screen. Table numbers are configurable: Fargo Billiards runs tables 24–44 today (used here); the May 2027 event may have 50–60 tables — Jon will give the details. Scores are sample until match scoring (F-32) is wired, then they go live. This is the “own the room” experience a static bracket tool can’t give you. Builds on F-16 (spectator/overlay) + F-46 (live clocks). For Jon to react to. (see the demo →) |
| F-48 | Planned | ★ WOW — Shareable player “trading cards” A gorgeous shareable card per player — full flag, FargoRate, record, longest run, earnings — like a FIFA/baseball card. Players share them → markets the event. Builds on the player cards (F-14). For Jon to review. |
| F-49 | Planned | ★ WOW — Live room-heat view The whole room at a glance — every table glows green→amber→red by how long its match has been running, so the TD instantly spots the logjam. Builds on slow-player tracking (F-41). For Jon to review. |
| F-50 | Planned | ★ WOW — Post-event shareable recap card When the event ends, each player gets an auto-generated shareable recap — finish, earnings, longest match, break-and-runs — built to post to social. Free marketing after every tournament. For Jon to review. |
| F-51 | Prototype | Tournament dry-runs — practice a whole event here before a live one PROTOTYPE LIVE at /scenarios — the dry-run guide (seven scenarios to walk through); actually running them end to end is the next step. Open this to see what it entails. Before you ever run a real tournament on this, you walk a full event through the app here — register the field, run the bracket, calculate the payout, text the players. Every scenario you run now is a bug we catch in practice instead of live on tournament night. This is also how support stays simple: a dev standing by during a live tournament is expensive and is not how apps are meant to run — hardening it in dry-runs is what lets tournament day be boring. The exact support model (who you call, how fast, what PWW commits to) is a conversation with Ryan; the dry-runs are how we make that conversation cheap. For Jon. (see the demo →) |
| F-52 | Planned | Entry record + rating LOCK (date, who took payment, “locked in”, rating frozen at a cutoff) Critical fairness rule from Jon. Each entry stamps: date entered, date paid, who took the payment (TD), and “locked in” for THIS event — like PPMU. The key part: a player’s FargoRate is LOCKED at a defined moment, not read live on event day. Example: a player is 544 at Monday league, drifts to 547 by the 21st; if we checked the live rating we’d turn away a player who was legal when they entered. So the FargoRate link PULLS the rating at lock time and freezes it (“rating as of …”). Eligibility against the cap (F-23) uses the LOCKED rating. RESOLVED (Jon): the lock point is PAYMENT — when a player pays their entry, their FargoRate is frozen for that event; a day-of increase doesn’t matter. (PPMU worked this way: the TD could see who had paid, and paying locked them in.) So the TD screen shows paid/unpaid, and “paid” = rating locked. IMPORTANT: PAID — not promised. Players notoriously say “enter me on socials” or text Jon/Amanda “I’m on my way”; that is a request, NOT a locked entry and does NOT hold a spot. Only payment locks. This is why each event has a registration CUTOFF time (F-22) — a hard deadline so the TD has time to set up and draw the bracket. So an entry has states: requested → registered → PAID/locked. Refines F-23 (caps) + F-27 (payment tracking) + F-22 (cutoff). (see the demo →) |
| F-53 | Planned | Player profile — “Last tournament” + date Jon’s add: show on each player’s profile the last tournament they played and the date. Two honest sources: (1) once events run in Run the Bracket, “last tournament” is simply their most recent entry (falls out of the entry record, F-52) — no extra data entry; (2) the FargoRate link also reports a last-activity date, useful for spotting a stale rating before an event. Lives on the player card (F-14). For Jon. (see the demo →) |
| F-54 | Prototype | Locked-rating badge on the bracket (tap to see “was under the cap when they paid”) Jon’s transparency idea — so an opponent can trust a player belongs in the event. Each player’s rating is a tappable badge; tap it and a little box pops up: “✅ Locked at 544 — frozen when they paid, so a day-of change doesn’t affect eligibility.” Defuses the “but they’re 547 now!” argument at the table. On a tablet/phone a hover tooltip won’t work, so it’s tap-to-open. PREVIEW LIVE on the Roster now (tap any rating). Next: same badge on the bracket. Builds on F-52 (rating lock) + F-25 (FR on bracket). (see the demo →) |
| F-55 | Planned | Register from the shared link — flyer, Facebook post, or a comment Jon/Annabel: pool players live on Facebook. When Jon or Amanda posts the event (flyer, a post, or even a reply in the comments), the registration link should let a player tap and register — and pay — right from there. The link is already public; this makes it the front door for social sign-ups. A “request to enter” from a comment is still just a request until they PAY (F-52) — so the shared-link flow should push them to pay to actually lock their spot before the cutoff. Builds on F-04 (QR sign-up), F-21 (flyer), F-03 (payment), F-39 (share link). (see the demo →) |
| F-56 | Planned | Payment confirmation to the player (receipt + “you’re locked in”) When a player pays, send them a confirmation — their receipt and their proof they’re in: “You’re paid & locked in for [event] on [date], rating locked at [X]. See you there.” This is the moment PAID = locked (F-52) becomes visible to the player. Goes by text and/or email (F-28); real sending needs the paid texting/email service (your go-ahead). Not built yet. Pairs with F-27 (payment tracking) + F-28 (confirmations). (see the demo →) |
| F-57 | Prototype | Venue / pool-hall logo + branding (upload a logo per location) PROTOTYPE: a logo can be uploaded per EVENT when the TD creates it (Create event, safe image upload) and shows on that event’s page; an event without its own logo shows a monogram tile. A logo stored once per VENUE is not built yet — every event’s “Hosted at” line shows the Fargo Billiards logo today. Annabel: let each pool hall / location upload its logo, then brand its events with it — on the event page, the bracket, the big-screen display, and the shareable cards. Makes every tournament look like the HALL’S event, not a generic app (a key “own the room” differentiator). We already have safe image upload built (the flyer/photo upload), so this reuses it. We even have Fargo Billiards’ logo from the flyer Jon sent to seed the first one. Builds on F-13 (venues) + the upload engine + F-21 (flyer). (see the demo →) |
| F-58 | Planned | DRAFT — message Jon can send to Mike Page (FargoRate founder) to request data access For JON to review, edit, and send — this is a draft, not sent by us. Goal: get Jon access to FargoRate data so Run the Bracket can pull a player’s rating at sign-up, FREEZE it at payment (F-52), and keep the “X & Under” caps (F-23) honest. CONTEXT (from Annabel/Amanda): Amanda has spoken with Mike and thinks he’ll say yes — he wants the event data. Annabel’s worry is the opposite: that Mike may not love that we’re building our own tournament app. We know FargoRate has one developer (Jackson) building a tournament app of their own; it was NOT used for the 505 this past weekend because things were still broken, and the requirements/questions list FargoRate sent last week still has no answer. STRATEGY baked into the draft below: lead with a DATA-ACCESS + two-way-data partnership ask (ratings in, tournament results back to FargoRate — which is what Mike wants), and do NOT open by announcing a competing app. It frames Run the Bracket as something that FEEDS FargoRate clean event data, which de-risks Annabel’s concern. Jon can soften, sharpen, or rewrite entirely. NOTE: the actual live FargoRate link / API is a separate step that needs Annabel’s go-ahead before we wire it (ties to F-25 FR on bracket + F-52 rating lock). ✍️ Draft to send — Jon can edit Hey Mike,
Wanted to run something by you. When I’m running events, the thing I keep bumping into is rating accuracy right when a player pays — a guy can drift a few points between league night and tournament day, and I don’t want to turn away someone who was legal when he entered. If I could pull ratings (and last-activity) straight from FargoRate, I could check at sign-up, lock the rating when they pay, and keep the “X & Under” caps clean.
I’d send the event data back your way too — brackets, finishes, head-to-heads. I know that’s the stuff you want, and I’m happy to be a steady source of it.
Got a few minutes to talk about what access could look like, and how you’d want the results sent back?
Thanks Mike — appreciate it.
— Jon |
| F-59 | Prototype | Live “how many are registered” count per event — that Jon can read & post Jon (via Annabel, 2026-10-20): he regularly needs — and posts — how many players are already registered/paid for a specific event (e.g. a Facebook update: “42 in so far, 18 spots left”). He needs that number on demand FROM THIS APP. PROTOTYPE LIVE (2026-10-20): each EVENT (F-61 /events) now shows a live registered/paid count computed from real entries tied to that event, plus a ready-to-post one-line version (“Nov 21st 545 & Under: 7 in, 53 of 60 spots left”) he can copy onto the flyer post or in the comments. Paid = locked (F-52). KEY DISTINCTION: this is a count of entries for ONE event, NOT the master player directory (/roster) — it lives on the event page. Still to come: a one-tap copy button + share styling (F-50); the count becomes fuller once real payment (F-03) and register-from-link (F-55) feed it. Pairs with F-60 (cap), F-21 (flyer), F-27 (payment tracking). (see the demo →) |
| F-60 | Prototype | Field cap + waiting list (“first 60 paid”, then a wait list) Jon (via Annabel, 2026-10-20): events often cap the FIELD SIZE, not just the rating — e.g. the flyer says “first 60 paid.” Once 60 have PAID (paid = locked, F-52), the event is full and Jon starts a WAITING LIST. PROTOTYPE LIVE (2026-10-20): an event (F-61 /events) carries a field cap, and entries now overflow automatically — the first N PAID entries are seated IN the field, the rest drop to an ordered WAITING LIST; an unpaid request holds no spot (stays pending). The event page shows In / Spots-left / Wait-list / Pending at a glance and warns when the field is full. AUTO-PROMOTE NOW LIVE (2026-10-20): each paid entry has a "Drop" button; when a seated player is dropped the next on the waiting list moves into the field automatically — seat status is recomputed from the active paid entries in sign-up order every time the page loads, so nothing is ever left stranded and no spot is wasted. TWO caps shouldn’t be confused: RATING cap (F-23, “505 & Under”) vs FIELD-SIZE cap (this, “first 60 paid”); both now enforce at entry. Pairs with F-59 (count), F-55 (register from link), F-27 (payment), F-22 (cutoff). (see the demo →) |
| F-61 | Prototype | Events as a first-class thing — a tournament players register INTO STRUCTURAL KEYSTONE (identified with Annabel, 2026-10-20). Today registration saves everyone to ONE shared player list (the Roster). To do the things Jon needs, the app has to understand that an EVENT is its own thing and an ENTRY belongs to a specific event — e.g. “the Nov 21st 505 & Under.” PROTOTYPE LIVE (2026-10-20): open /events — you can create an event with its own name, date, game, rating cap (“505 & Under”), field cap (“first 60 paid”), entry fee and added money; each event is saved to the server and shows its own rules on a card. ENTRIES NOW WIRED (same day): open an event and enter players INTO it — each entry belongs to that specific event, so the registered/paid count is REAL (not a placeholder), the rating cap enforces at entry (F-23, proven: Jon Brown 689 is turned away from a 505 & Under), paid = a locked seat (F-52), and the field cap overflows to an ordered waiting list (F-60). The keystone now works end-to-end: an event carries its own rules AND its own field, instead of everything being a property of the global roster — the per-event count (F-59), field cap + waiting list (F-60) and rating cap at entry (F-23) are all live off this. Still hanging off it: the rating LOCK at payment (F-52), auto-draw from an event’s field (F-05), payouts for that event (F-19), flyer/logo per event (F-21/F-57), register-INTO from the public link (F-55). NEXT RUNG: register INTO an event from the registration/pay flow + real payment (F-55/F-03), and auto-promote the wait list when a paid spot frees up before the cutoff (F-22). This is why those items cluster — they all depend on this. Builds on F-22 (event setup fields) + F-01 (players) + F-13 (venues). (see the demo →) |
| F-62 | Prototype | “Go Live” — turn a player’s phone stream into the event’s broadcast Annabel’s idea (2026-10-20, “think way outside the box, best in class”): players prop a phone and stream their match to Facebook. Her UX: the “you’re up” text (F-29) already carries the SCORING link — add a SECOND tap, “📹 Streaming this match? Tap here,” that opens a go-live helper. PROTOTYPE LIVE at /golive (and the CTA is now in the you’re-up text on /score). THE HONEST DIFFERENTIATOR: we do NOT ship the “I don’t own the rights to this music” disclaimer everyone parrots — it does NOTHING (Facebook auto-mutes copyrighted bar music regardless; a spoken disclaimer grants no license). Best-in-class = tell the player the ONE thing that actually works (keep the jukebox out of the stream’s audio; let the room + commentary be the sound) — a 3-step don’t-get-muted checklist. Then make every phone a real broadcast: a pre-filled Facebook caption (players, ratings, round, venue + a sign-up link), a courtesy card framed honestly (not a legal shield), and — the part no other player-stream has — the LIVE SCORE overlay riding on their stream (F-16/F-32). THE BIG BET: every propped-up phone becomes a camera the TD can FEATURE on the big board (F-47) + spectator page → a crowdsourced multi-angle broadcast at zero cost, and every viewer is one tap from registering for the next event (F-55) → a marketing flywheel. Real today: the checklist, caption, courtesy card. Rides on other rungs: live-score overlay (F-32), feature-a-stream (F-16), register-from-stream (F-55), highlight card (F-50). For Jon to react to. Builds on F-29 (you’re-up text) + F-16 (spectator/overlay) + F-47 (LIVE board). (see the demo →) |
| F-63 | Prototype | Share your match & bracket with family (the personal, not-marketing share) Annabel (2026-10-20): "players may also want to post their match or the bracket to loved ones." A key insight — not all sharing is marketing. Lots of players just want their MOM, spouse, or kids to watch. PROTOTYPE LIVE on /golive: alongside the public Facebook caption (F-62) there’s now a separate, warmer PERSONAL share — a pre-filled message ("Come watch me play! I'm up next on Table 2 — cheer me on ❤️") with a one-tap copy to text/DM a loved one. THE REAL VERSION (next rungs): a per-player link (runthebracket.app/me/<player>) that opens a FOLLOW view showing just THAT player's path through the bracket, who they play next, which table, and their live score — so family who aren't at the hall can follow and get a ping when their person is up or advances. This is the personal twin of the spectator page (F-16) and uses the same bracket data; it also feeds the shareable player card (F-48) and post-event recap (F-50) — "I finished 3rd! ❤️". Distinct tone from the marketing share on purpose. ALSO (Annabel, same night): sharing must be available to any PLAYER, not just the TD — a player can grab and pass along the whole BRACKET link or the TOURNAMENT/event link (so a friend can come play or register, F-55), not only their own spot. PROTOTYPE on /golive now has a "Share links" block with all three (tournament · bracket · my spot), player-facing by design. Builds on F-16 (spectator) + F-36 (bracket share/export) + F-39 (bracket link text) + F-55 (register from link) + F-48/F-50 (cards). (see the demo →) |
| F-64 | Prototype | A real public landing page — the front door (NOT the brain-dump) PROTOTYPE LIVE at /tournaments (2026-10-20) — a clean player-first front door: scannable tournament cards (monogram tile, not a screen-eating flyer), one search, Open/Full + per-game filters, find-a-player / watch-live, and "Create one" as a small link (not the whole page). Annabel (2026-10-20, comparing DigitalPool + Challonge landing pages — "both horrible, not UX friendly", "we must be better!"). The site root now sends the public to /tournaments; the BRAIN-DUMP intake (Annabel/Jon’s private talk-to-me page) stays at the root for the signed-in TD only. WHAT TO AVOID (from the two competitors): DigitalPool dumps "1–20 of 92,030" tournaments globally with a giant featured flyer image eating the whole screen (you can see ONE event without scrolling), tiny crammed filters, notification clutter — a player can’t answer "what can I enter, near me, soon?". Challonge shows TWO identical "CREATE A TOURNAMENT" buttons + an empty shell + "Commence Battle" (esports/gamer voice, wrong audience for APA pool). BEST-IN-CLASS DIRECTION: a clean, PLAYER-FIRST landing — scannable upcoming-tournament cards (date · game · cap · entry · spots left) with the flyer as a small thumbnail (not a screen-eating hero), scoped to near-me / this series, with find-and-follow front and center (not create-create-create). Prominent simple SEARCH (F-65). TD "create" is available but not the whole page. Builds on F-61 (events) + F-65 (search) + F-24 (series) + F-55 (register from link). (see the demo →) |
| F-65 | Prototype | Search — find a tournament (name / venue / game / date) and find a player PROTOTYPE LIVE on /tournaments: a live search filters the REAL events by name/venue/game as you type, with Open/Full + per-game filter chips and a live "showing N of M" count. Annabel (2026-10-20): "needs the search option." Confirmed GAP: we have player-name search on the big screen (F-08) but NO tournament search, and the /events list has no search/filter bar. DigitalPool’s is cluttered but the NEED is real. Best-in-class: a single clean search on the landing (F-64) + /events that finds a tournament by name, venue, game, or date, plus a few real filters (game, status: upcoming/open/full/done) — and a players search (ties to F-08 / F-30 FargoRate lookup). Must stay simple and scannable, the opposite of the competitor clutter. Extends F-08 (player search). Pairs with F-64 (landing) + F-61 (events). (see the demo →) |
| F-66 | Prototype | TD tracking & growth — is the series growing, is a format working? Annabel (2026-10-20): "On the TD admin page he will want tracking — so they can determine growth, or if they need to change something up in their format etc." The TD view shouldn’t just run TODAY’s event; it should show the SERIES over time so Jon can make decisions. REAL DATA TO BUILD ON (confirmed this night): the full Fargo Billiards 2026–27 monthly series is now seeded as real events (Nov 21 545 & Under → May 12–16 Season Finals), and the Oct 17 505 & Under drew 48 players (Annabel, corrected from an earlier 28). So the substrate exists: entries-per-event over the calendar. PROTOTYPE LIVE (2026-10-20) at /tracking: a read-only season dashboard — a turnout bar per event across the calendar (solid = recorded final turnout for a completed event, striped = live paid sign-ups "so far"), a trend arrow vs the previous event, fill-rate against the field cap, the format label per event, and a few plain-language insights (biggest draw, growing/shrinking, formats on the calendar). The Oct 17 505 (48 players) seeds as a completed event so the growth line has a real first point; events carry a recorded final turnout (attendance) once they finish. BEST-IN-CLASS DIRECTION: a TD dashboard that plots turnout per event across the season (48 at the 505, N at the 545, …), flags trend (up/down/flat), and slices by FORMAT (handicapped vs X-&-Under vs Scotch Doubles) and by RATING BAND so Jon can SEE which formats pull a crowd and which to rethink — plus fill-rate vs field cap (did the 60-cap fill? how fast?), no-shows, and repeat vs new players. The point is a DECISION tool, not vanity stats: "the doubles night is shrinking — try something else," "478 & Under fills fastest — add one." Starts from counts we already compute per event (F-59) and the seeded season (F-24). Needs the secure TD view (F-20) so only Jon sees it. Builds on F-61 (events) + F-59 (per-event count) + F-24 (series) + F-20 (TD auth) + F-19 (results/payouts history). (see the demo →) |