Subject: Hire Request: WeWeb + Supabase Web App Prototype (Badminton Score Tracker)
Hi there,
I am looking for an expert WeWeb and Supabase (PostgreSQL) developer to build a clean, friction-free score-logging web application prototype for a badminton club network.
Please review the full details below. Because this app handles player names, it is designed strictly around data protection, user privacy, and consent compliance rules.
Project Logistics
- Tech Stack: WeWeb (Frontend) + Supabase (Backend/Database).
- Target Timeline: 7–14 days.
- Contract Type: Fixed price.
DETAILED PROJECT BRIEF
The Goal: A responsive web application supporting multiple independent clubs (club_idseparation). It must work perfectly on a central desk iPad or on players’ mobile phones via a session QR code.
CRITICAL REQUIREMENT: Individual players must NOT register an account, log in, or download an app. They interact purely via the public, responsive web views. The entire system must fit inside the FREE TIERSof WeWeb and Supabase for this rollout phase.
Core Workflow & Features:
- Organizer Admin Panel (Supabase Auth): A club organizer logs in, creates a club profile, and inputs player names. The system generates a custom session web link and matching QR code for that club.
- Unified, Responsive Score Screen: A single WeWeb page displaying a visual grid of active courts (e.g., Courts 1–4).
- Dual-Input Score Entry (Supabase Realtime): Players scan the QR code or use the desk iPad, tap a court, select 4 names from a dropdown, type the scores, and hit submit. The central iPad screen must update instantly.
- Week-to-Week Player Rating Engine: All players start at 1,200 points. A backend database trigger automatically updates skill ratings based on wins/losses, carrying over permanently week-to-week.
- Fair-Play Queue Optimization (Dropdown Sorting Logic): To prevent court hogging, the system tracks games played per session (resets to 0 each night). The player dropdown menu must sort dynamically: players with the lowest number of played matches that evening appear at the very top with a visual tag (e.g., “John Doe (1 game)”).
- Dynamic Presence Toggle (Active vs. Absent Status): To handle players who sign on but don’t show up or leave early, the roster needs a simple “Present/Absent” toggle switch. The score entry dropdown menus must strictly filter out anyone marked as “Absent.”
DATA PROTECTION & GDPR COMPLIANCE (Mandatory)
The architecture must strictly enforce these data protection guidelines:
- Explicit Admin Consent Checkbox: On the Organizer Admin Panel, there must be a mandatory, un-ticked checkbox: “I confirm that I have obtained verbal or written consent from these players to input their names into this tracking system for game logging purposes.” The admin cannot save the roster without ticking this.
- Public Footer Privacy Notice: At the bottom of the scoreboard, a “Privacy info” link must trigger a static text modal stating:“This application is a prototype built to track club scores and calculate casual skill ratings. We only store player names and match scores. We do not collect emails, phone numbers, or tracking cookies from players. Data is kept securely in our database and will never be shared or sold. If you want your name removed at any time, please tell the club organizer.”
- Data Minimisation: The database must only hold the absolute bare minimum text data (names, IDs, score digits). Absolutely no personal identifying details (PII) like emails or phone numbers are to be captured for players.
MANDATORY APPLICATION QUESTION
To prove you have read this entire message and understand database architecture, please start your reply by answering this exact question:
“Briefly explain how you plan to handle the database structure in Supabase so that Club A’s players never accidentally show up on Club B’s dropdown menu.”