What is LET?

LET is a mobile app that lets tennis players discover, match with, and message other players at their skill level — the same way a dating app connects people. You swipe on player profiles. When two players both swipe right on each other, it's a match. From there, you chat directly inside the app and arrange a time to play.

Core Features (MVP)

Why LET — The Gap in the Market

Existing tennis apps fall into two categories: structured league platforms (UTR, Tennis Australia's competition system) or court booking tools (CourtReserve, ClubSpark). Neither solves the most common problem casual players face — finding someone to hit with this week. LET sits in the space no one has properly built for: spontaneous, social, player-to-player matchmaking. The Tinder mechanic is deliberately chosen — it's a pattern millions already understand, applied to a sport context for the first time at consumer scale in Australia.

What LET Is Not

Staying focused on the core problem means saying no to a lot of adjacent ideas. LET is deliberately not any of the following:

Tech Stack

LET is built on a modern, low-code foundation that allows rapid iteration without sacrificing reliability or scalability. Every component is a managed service — there are no servers to maintain.

Data Model

Four Firestore collections power the entire app:

Build Phases

LET is built one phase at a time. Each phase is completed and tested before the next begins — this keeps the codebase stable and the product shippable at every milestone.

• ✅
  Phase 1 — Firebase Foundation Complete

  • Firebase Auth enabled with email/password
  • Firestore collections created: users, swipes, matches, messages
  • Security rules written and published
  • LoginPage confirmed creating user documents on sign-up
• ✅
  Phase 2 — Create Profile Complete

  • Full profile form: name, age, suburb, city, club, bio
  • Chip selectors: skill level, match type, availability (Mon–Sun)
  • Save Profile writes all fields to Firestore users collection
  • Navigates to SwipePage on save (replace route)
• ✅
  Phase 3 — Discover / Swipe Page Complete

  • SwipeableStack showing live player cards from Firestore, filtered so users never see their own profile
  • Pass (✗) and Like (✓) buttons trigger left/right swipe gestures on the stack
  • On swipe: writes swipe document to Firestore (swiperId, swipedId, direction, timestamp)
  • App State variable currentPlayerId created for upcoming match logic
  • Swipes collection schema added to FlutterFlow project
• ✅
  Phase 4 — Mutual Match Detection Complete

  • App State variable lastSwipeDirection created — bridges button taps to On Page Swipe event
  • Pass (✗) and Like (✓) buttons wired to set direction ("left"/"right") before triggering swipe gesture
  • Swipe direction field fixed — was hardcoded "left", now reads from App State variable
  • On right-swipe: conditional action queries swipes collection for a reciprocal right-swipe (3 filters: swiperId, swipedId, direction)
  • If mutual match found: creates match document in matches collection (user1Id, user2Id, createdAt via Firestore server timestamp)
  • Match alert fires: Informational Dialog — "It's a match! 🎾"
  • LoginPage routing fixed — Sign In now navigates to SwipePage, Create Account navigates to CreateProfile
  • End-to-end test passed 16 May 2026 — two accounts confirmed mutual match detection, Firestore document created, alert dialog fired correctly
• ✅
  Phase 5 — Profile & Settings Complete

  • ProfilePage created by duplicating CreateProfile — instant layout and visual consistency
  • Firestore backend query wired to page Column: users collection → Single Document → uid Equal To Authenticated User ID
  • All text fields pre-populated from Firestore: display_name, age, suburb, city, club, bio
  • Skill Level, Match Type, and Availability ChoiceChips pre-populated via Initial Option from users Document
  • Save Changes button — Update Document action mapping 9 fields back to Firestore
  • Log Out button — Firebase Auth Log Out → Navigate to LoginPage (Replace Route)
  • Navigation wired to person icon in SwipePage bottom nav bar
  • End-to-end tested: data loads, save updates Firestore, logout returns to LoginPage
• ✅
  Phase 6 — GAMEON Page Complete

  • Full-screen GAMEON page (not a bottom-sheet) — split-screen photo layout with both players' faces filling the screen
  • Two profile photos side by side, each taking half the screen width and full screen height
  • Dark rounded card overlaid at the bottom centre with subtle transparency
  • "GAME ON" large bold white headline + "You and [Name] are ready to hit the court" subtitle (sport-first, deliberately avoiding Tinder-style "MATCHED!" language)
  • "Plan a Hit" primary button (filled, lime green) — stubbed for Phase 7 with snackbar, will navigate to chat thread once chat is built
  • "Find More Players" plain text link below the button — Navigate Back to SwipePage
  • Page parameters: matchedUserName (String), matchedUserPhoto (ImagePath, required), matchedUserId (String)
  • SwipePage wired: replace "It's a match!" informational dialog with Navigate To GAMEON action, passing swiped user's display_name, photo_url and uid

  

  GAME ON

  You and Alex are ready
  to hit the court

  Plan a Hit

  Find More Players

  Design Mockup

  GAMEON Page

  Full-screen takeover that fires on a mutual right-swipe. Replaces the placeholder "It's a match!" alert dialog from Phase 4 with a branded experience.

  Split-screen photos of both players, sport-first headline ("GAME ON" not "MATCHED!"), a single primary CTA ("Plan a Hit") that opens chat in Phase 7, and an escape-hatch link ("Find More Players") that returns the user to SwipePage. Photo, name, and matched user ID are passed in as page parameters from SwipePage.

• 🏗️
  Phase 7 — Matches & Chat In Progress

  Phase 7 — Progress Report (updated 4 June 2026)

  Matchmaking foundations (22–25 May): Three days of prep work shipped 9 binding/configuration fixes across the swipe-action chain. The matchmaking flow is now fully working end-to-end — verified by a two-account live test where both accounts mutual-matched and the GAMEON page loaded cleanly on both sides with correct names, photos, and no security-rules errors.

  MatchesListPage complete (25–29 May): Page scaffolded via FlutterFlow's Designer AI, page-level Firestore Backend Query wired (OR filter: user1Id == auth.uid OR user2Id == auth.uid), and the eight static placeholder rows replaced with a single MatchRow inside a ListView generated from the query. Each row now resolves "the other user" (the participant who isn't you) and binds the displayed name, photo, and level to that user's real profile. The matches list is functionally done.

  ChatThread complete + verified (29–31 May): bound message timestamps and sent/received bubble alignment, fully wired the send-message button (writes sender + text + a Firestore server timestamp to the match's messages subcollection, then clears the input), wired navigation from a match row into its chat, and built the chat header (the other user's real name + photo). The whole chat experience was then verified end-to-end in a two-account live test — both players saw the correct person in the header, and messages sent and arrived correctly in both directions. The core app loop — discover → match → chat — is now functionally complete and demoable.

  GAMEON link + Report user shipped (1 June): the GAMEON "Plan a Hit" button now opens the right chat thread — and building it surfaced a genuine FlutterFlow bug (a freshly-created match reference can arrive empty through navigation and crash the destination screen). Fixed by routing the reference through a stable app-wide value; verified in a two-account live test — both sides land in the correct conversation with no crash. Report user is also live and verified end-to-end: an info button in the chat header opens a confirmation dialog, and confirming writes a report to a locked-down Firestore reports collection (with a link straight to the reported conversation for review). That's LET's first Apple Guideline 1.2 safety requirement, done. Still to build in Phase 7: a shared Report / Unmatch / Block safety menu, a report reason-picker, a security-hardening pass folded in before Block (participant-only Firestore rules on messages + matches, Firebase App Check, auth hardening), unmatch, block, an account-deletion screen (Apple-mandatory), and an 18+ age gate on signup. Honest remaining estimate: ~9–15 focused hours; block-user, account-deletion, and the security pass are the heavy items. Update 4 June: the SafetyMenu — the shared Report / Unmatch / Block sheet — is now wired and verified working: the chat-header info button opens it as a bottom sheet (passing the other player, the match, and their name), and the Report flow was relocated onto the menu's Report row and re-wired to the menu's parameters. Confirmed in a live test — info button → menu → Report → confirmation → report saved. Update (4 June, later): the report doc was re-verified writing correctly after the menu move; work then began on the report reason-picker (a dedicated reason sheet, with the first reason wired) but was parked mid-build to protect the working report, and a first slice of the security pass landed — an auth password policy (enforced complexity + minimum length). Next: finish the reason-picker, then the main security-hardening pass (participant-only Firestore rules + App Check), then Unmatch and Block.

  • Prep work — done 22–24 May 2026: A blocking bug in the matchmaking flow was discovered before Phase 7 build could begin. Mutual swipes weren't creating matches documents in Firestore, which would have made the chat feature impossible to test. Root cause: four separate field bindings in the SwipePage swipe-action chain were reading an unreliable uid field on user documents instead of the document's own reference ID. All four bindings rebound to use Document Reference ID; mutual match flow now verified end-to-end with two real test accounts. Junk data cleared, clean slate for Phase 7 build.
  • Action 4 navigation fix — 25 May 2026: The Navigate-to-GAMEON action's matchedUserId parameter had the same broken pattern as the prep-work bindings. Rebound to Document Reference ID. Two-account live test confirmed mutual match → GAMEON now passes the correct matched user ID, ready for chat hand-off.
  • MatchesListPage scaffold + query — 25 May 2026: Generated via FlutterFlow's Designer AI (page, reusable MatchRow component, sport-first subtitle, placeholder rows + empty state). Page-level Backend Query also wired on the matches collection with an OR filter (user1Id == auth.uid OR user2Id == auth.uid). The page now has its data source; rows still need to be bound to dynamic results.
  • MatchesListPage dynamic rows — 28 May 2026: Replaced the eight static MatchRow placeholders with a single MatchRow inside a ListView, wired to the matches query via "Generate Children From Variable" (loop variable: matchDoc). The row's name parameter is bound to a field on the loop variable, confirming real Firestore data flows row-by-row.
  • MatchesListPage — other-user resolution complete (29 May 2026): each row now resolves the participant who isn't the current user and binds the row's name, photo, and level to that user's real profile (conditional value + a nested users Backend Query inside MatchRow). The matches list is functionally done.
  • ChatThread — message list live (29 May 2026): messages render dynamically from the match's messages subcollection via FlutterFlow's Generate Dynamic Children (loop variable messageDoc), with each bubble's text bound to its own message. Incoming messages display in real time.
  • ChatThread — timestamps, bubbles & send button (29 May eve): each message's timestamp renders in 12-hour time, sent vs received bubbles align by comparing the message's sender to the logged-in user, and the send button is fully wired (writes sender + text + a server timestamp to the messages subcollection, then clears the input). The AI-generated "input" turned out to be a non-interactive box — a real text field had to be added before send could work.
  • ChatThread — match-row navigation (29 May eve): tapping a match opens that match's chat thread, passing the match reference through so the right conversation loads.
  • ChatThread — chat header complete + verified (31 May 2026): the header shows the other user's real name and photo, resolved the same way the match rows are (a conditional picks the participant who isn't you, feeding a single-document users query). Verified in a two-account live test — both sides showed the correct person, and messages sent/received correctly in both directions.
  • GAMEON "Plan a Hit" → chat (1 June 2026): the button now opens the matched conversation. The match reference is captured when the match is created, carried through a stable app-wide value (working around a FlutterFlow bug where a fresh reference goes empty through navigation and crashes the screen), and passed into the chat. Two-account live test passed — both sides open the correct thread, no crash.
  • Report user — done & verified (1 June 2026): an info button in the chat header opens a "Report this player?" confirmation; confirming writes a report (who, whom, reason, time, plus a link to the conversation) to a locked-down reports Firestore collection, then shows a thank-you message. Verified end-to-end with a real report landing in the database. Satisfies Apple Guideline 1.2's report-objectionable-content requirement. Updated 3 June: the report now also stores the reported player's display name, so the moderation queue reads as real names instead of anonymous IDs — the first piece of the report reason-picker upgrade (a Harassment / Spam / Safety / Other reason menu lands next).
  • Safety menu — built & wired (4 June 2026): the chat-header info button now opens a shared Report / Unmatch / Block menu (a bottom sheet), so all three safety actions hang off one structure instead of being built separately. The Report flow was moved onto the menu's Report row and re-wired to the menu's parameters; verified in a live test — the info button opens the menu and Report runs end-to-end. Unmatch and Block are the next two rows to wire.
  • Report reason-picker — in progress (started 4 June): let the reporter choose a reason (Harassment / Inappropriate / Spam / Safety / Other) instead of the current hardcoded value. A dedicated reason sheet has been cloned and the first reason wired; the remaining reasons and the hand-off from the safety menu are still to do
  • Security hardening (before Block) — partly started: the auth password policy is now enabled (4 June) — enforced complexity (upper, lower, number, symbol) and an 8-character minimum. Still to do, as a focused session: tighten Firestore rules so conversations are readable and writable only by the two matched players (today any signed-in user could reach a conversation through the data layer), enable Firebase App Check, and switch on email-enumeration protection — then re-verify chat. Done before Block so the block is enforced by the rules, not just hidden in the UI
  • Unmatch — either player can remove a match at any time
  • Block user — removes the match, prevents future matching, hides profiles from each other; enforced server-side by the hardened rules
  • Account deletion — in-app settings screen that permanently deletes Firestore profile and Firebase Auth account (Apple mandatory since 2022 — guaranteed rejection without it)
  • Date of birth field — added to CreateProfile to enforce 18+ age gate at signup

  Ways of Working — lessons banked in Phase 7

  Phase 7 has run to ~26 hours so far — about 2 hours a night, nearly every night from 22 May to 4 June — against a 3-hour estimate. The gap is scope that surfaced during the build, not slipping pace: the original guess never priced in Apple's mandatory safety features or the wiring of AI-generated UI (which hands over polished layout but zero working logic). The overrun produced five working rules now applied to every phase:

  1. AI-generated screens are layout only. FlutterFlow's AI generation produces visual scaffolding — placeholder text, fake buttons, sample data. Connecting it to live data and actions is the real work, now priced as the bulk of each build rather than an afterthought.
  2. Audit before building. Confirm what's actually wired versus placeholder (real input field or a styled box? real query or sample data?) at the start of a phase. "Looks finished" never means "is finished."
  3. Finish, don't defer. Stuck problems get solved in the same session rather than pushed to "later" — quiet deferral is what inflates scope.
  4. Verify the path before executing it. Check an approach actually works before building on it, so effort isn't thrown away.
  5. Verify it saved before building on it. New or duplicated pieces are confirmed as actually persisted before more work is stacked on them — and nothing is recorded as "done" until it's verified. A status should reflect what's real, not what's hoped.
• 🛡️
  Phase 7.5 — Content Moderation (Mini Phase) Upcoming

  • Required for Apple App Store approval — Review Guideline 1.2 mandates filtering for UGC apps. Guaranteed rejection without it
  • Client-side banned-word filter via FlutterFlow custom function — checks input on save, shows error toast if matched, blocks the write
  • Applies to three input points: bio field, display_name field, chat messages (Phase 7)
  • Banned-word list covers slurs, swears, threats, sexual content — maintained as a constant in the custom function
  • Optional upgrade post-launch: Cloud Function + OpenAI Moderation API for smarter context-aware filtering
  • Must ship before TestFlight submission — not after
• 🔍
  Phase 8 — Polish, QA & Edge Cases Upcoming

  • Profile photo upload — built in this phase (deferred from CreateProfile). MANDATORY at signup — no photo, no save. Photoless profiles read as bot/catfish accounts and break the GAMEON split-screen layout
  • In-app cropping UI with a circular face guide overlay so users centre their face. Required because the GAMEON page split-screen layout breaks visually if the face is off-centre (e.g. one player's face vs. another player's leg)
  • Photo upload guidelines — clear pre-upload prompt: "Upload a clear photo with your face centred. Photos that don't show your face clearly may be rejected"
  • Existing test users without photos — forced to upload on next login via a one-time gate screen before they can access SwipePage
  • Optional: Firebase ML Kit face detection on upload — auto-reject photos with no detectable face, or auto-crop to the detected face bounds
  • Empty state: no players left to swipe — friendly screen encouraging users to check back later
  • Empty state: no matches yet — encouraging prompt so the screen isn't blank
  • Empty state: no messages in a chat — conversation starter prompt
  • Loading states — skeleton screens while Firestore data loads (prevents blank flashes)
  • Error handling — network errors, Firebase outages, graceful fallbacks with user-facing messages
  • Full device testing — iPhone SE (small screen) through iPhone Pro Max (large screen)
  • Edge cases — duplicate match prevention, simultaneous swipe handling, deleted account handling
  • No placeholder or test content in the submission build — Apple will reject dummy data
  • Carried-forward bug list (updated 24 May 2026): SwipePage filter not excluding current user (logged-in user can swipe their own card, creating self-match docs); X (Pass) button still triggers mutual match — lastSwipeDirection App State not updating to "left" before the swipe action fires; Authenticated User Photo URL on Firebase Auth side stays empty — needs to sync from Firestore photo_url on save; Left/right photo binding order on GAMEON page is the reverse of the original intent (left should be current user, currently rendering as matched user); Firestore Security Rules error toast on GAMEON page load — likely a Backend Query on matches collection without proper filters; Action 4 (Navigate to GAMEON) matchedUserId parameter likely still uses the old field-reading pattern and needs the same Reference ID fix applied during Phase 7 prep.
  • Location autocomplete (noticed during testing, 5 June 2026): the City and Suburb fields need Google Places Autocomplete so users select a real location from a dropdown — no typos or made-up places. It also returns latitude/longitude, the foundation for the distance filter (deferred to post-launch — see Phase 13).
  • Input quality & UX: spell-check on the bio field (red-underline on misspellings); profile photo upload confirmed not working in testing and must be fixed; show the password requirements (8+ characters with an uppercase, lowercase, number and symbol) on the Create Account page so sign-ups don't fail blind.
• 🎨
  Phase 9 — Brand & Design System Upcoming

  • Design direction (set 4 June): rebuild the app's UI to match the interactive prototype's look — the approved visual language (clean white cards, brand purple with a lime accent, rounded modern iOS style, sport-first). The prototype is the reference the FlutterFlow screens get restyled toward.
  • Look unique, not stock (added 5 June): the "generic low-code app" tell is default fonts, default components, and default spacing — not the colour. Explore distinctive colour schemes and custom fonts (not the platform defaults) and style custom components, so LET reads as a real brand, not a template. Colour (purple + lime) is already ownable; uniqueness is won on type and components.
  • Logo suite — wordmark, icon mark, lockup variations (light/dark)
  • Colour system — primary, secondary, semantic (success/error/neutral) with hex, RGB, and accessibility contrast ratios
  • Typography — typeface selection, scale (H1–body–caption), weights, line heights
  • Tone of voice — brand personality, vocabulary, writing principles, do/don't examples
  • UI component styles — buttons, cards, chips, inputs, modals applied to FlutterFlow theme
  • App icon & splash screen — all required iOS sizes
  • Brand guidelines document — single source of truth for all future creative
• ⚖️
  Phase 10 — Legal & Compliance Upcoming

  • Privacy Policy — GDPR/Australian Privacy Act compliant, hosted publicly (required for App Store)
  • Terms of Service & User Agreement — covers acceptable use, match disputes, content standards
  • LET trademark application — register with IP Australia (word mark + logo mark)
  • Apple Developer Program — enrol at developer.apple.com ($149 AUD/yr subscription)
  • Data retention policy — how long swipe/match/message data is stored
  • Age gating — 18+ confirmed. Enforce via date of birth field on sign-up
  • Moderation process — documented response plan for user reports (Apple requires this)
• 🌐
  Phase 10.5 — Website & Domain (Mini Phase) Upcoming

  • Purchase domain — lettennis.app or lettennis.com.au via Cloudflare Registrar (~$10/yr at-cost pricing)
  • Netlify hosting — static hosting with auto-deploy from terminal (Personal plan, $9/mo, subscribed June 2026)
  • Point domain DNS to Netlify (one-time, ~10 min)
  • Build site as plain HTML/CSS — same workflow as the playbook, deployed via "netlify deploy --prod"
  • Home page — hero, feature overview, screenshots, "Join the waitlist" email capture form
  • /playbook — replaces tiiny.site as the canonical playbook URL
  • /privacy — privacy policy from Phase 10 (App Store mandatory)
  • /terms — terms of service from Phase 10 (App Store mandatory)
  • /support — contact / FAQ page (App Store mandatory — Support URL required field)
  • /press — brand assets and press kit for media outreach
  • Knocks out 3 App Store submission requirements at once: privacy URL, terms URL, support URL
  • Estimated build time: 6–10 hours across a focused session, post Phase 9 (brand) and Phase 10 (legal copy)
• 📣
  Phase 11 — Marketing & Pre-Launch Upcoming

  • Landing page — lettennis.com.au (or .app), email capture for waitlist
  • Social channels — Instagram, TikTok; content strategy before and around launch
  • Beta user recruitment — 20–50 real Melbourne tennis players via local tennis clubs, Facebook tennis groups, Meetup, and direct outreach to parks and rec centres
  • App Store optimisation (ASO) — keyword research, listing copy, category selection
  • Press & partnerships — local tennis clubs, Melbourne tennis communities, tennis media
  • Launch plan — soft launch strategy, timing, and post-launch feedback loop
• 🚀
  Phase 12 — App Store Submission Upcoming

  • Demo accounts — two pre-seeded test accounts with complete profiles, a mutual match, and messages exchanged. Credentials submitted in App Review Notes so Apple's reviewer can test the full flow
  • App Review Notes — written explanation of what LET does, step-by-step instructions for the reviewer to test swipe → match → chat
  • Support URL — live support page or dedicated email (e.g. help@lettennis.app) linked in App Store listing (required field — cannot submit without it)
  • Export compliance — declare encryption usage (Firebase uses HTTPS/TLS); select "Yes, exempt" under US export law in App Store Connect
  • Privacy Nutrition Labels — declare all data collected (name, email, usage data, identifiers) in App Store Connect
  • App Store listing — category (Social Networking), age rating (18+), subtitle, keywords, description, promotional text
  • App Store screenshots — required sizes: 6.9" and 6.5" iPhone; all using finalised brand assets
  • TestFlight beta with recruited Melbourne players — gather feedback, fix critical issues before public release
  • Apple review submission — respond promptly to any reviewer questions; typical review time 24–48hrs
  • Public App Store release
• 📍
  Phase 13 — Post-Launch Roadmap After Launch

  • Location-based discovery (distance / km radius) — high priority post-launch. Let players find others within a chosen radius of them — the heart of "find a local game fast." Requires: City/Suburb Places Autocomplete to capture latitude/longitude, coordinates stored per profile, and a geo radius query (Firestore has no native radius query — needs geohashing or a bounding-box approach). For safety, show approximate distance only ("~5 km away"), never precise coordinates. A multi-session feature, deliberately deferred to post-launch so it doesn't block MVP submission — but central to the long-term product.
  • LET Premium — unlimited swipes, profile boost, read receipts (from the monetisation roadmap)
  • Android release — expand beyond iOS once the iOS app is stable

Development Principles

LET is built with a clear philosophy: ship a focused, working product fast — then iterate. These principles govern every decision made during development, from platform choice to feature scope.

Built secure, not secured later

Security is treated as a feature, not a final checklist. LET's defence sits on the backend, where it cannot be bypassed: Google's Firestore Security Rules decide every read and write and are enforced on Google's servers — never in the app, where a determined user could otherwise reach around the interface. Below is what protects the app as it is built, the plan for users' information, and the plan for money once LET monetises.

1 · Securing the app as we build

2 · Protecting users' information

• Data minimisation — LET collects only what the product needs to work. Personal contact details such as email and phone are kept out of the broadly-readable profile data, so a player can be discovered without exposing private information.
• Privacy by design — a clear privacy policy and Apple App Privacy labels ship at launch, aligned with the Australian Privacy Act and the Australian Privacy Principles (APPs).
• User data rights — in-app account deletion permanently removes a user's profile and login (Apple-mandatory), giving users real control over their data.
• Breach readiness — built on managed Google infrastructure to shrink the attack surface, with awareness of Australia's Notifiable Data Breaches obligations.

3 · Protecting money (when LET monetises)

LET launches free. When Premium subscriptions and court-booking commission arrive, payment security is designed in from the start:

• No card data ever touches LET — payments run through PCI-compliant processors (Apple In-App Purchase for Premium; an established provider such as Stripe for bookings), so LET never stores or handles raw card details.
• Server-side validation — every purchase and subscription state is verified on the backend, never trusted from the app, to prevent spoofed or replayed transactions.
• Fraud & abuse monitoring — sensitive money logic runs in secure Cloud Functions with monitoring, keeping financial operations off the device and auditable.

Phase 3 — Build Report

SwipePage · 10 May 2026

What the App Can Now Do

Key Challenges Encountered

Phase 4 — Build Report

Mutual Match Detection · 11 May 2026

What Was Built

Key Challenges Encountered

Phase 5 — Build Report

Profile & Settings Page · 17 May 2026

What Was Built & Tested

Phase 6 — Build Report

GAMEON Match Page · 17–18 May 2026

What Was Built & Tested

Key Challenges Encountered

Phase 7 — Build Report In Progress

Matches & Chat · 22 May–4 June 2026 (and ongoing)

What's Shipped So Far

Key Challenges Encountered

Your Input Needed

The following items need a decision or action before LET can launch. None of these are technical — they sit in your lane. Each one is explained plainly below.