[Hiring] Responsive Badminton Score Tracker & Fair-Play Queue (WeWeb + Supabase)

Jobs & collabs
1

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.

:stopwatch: Project Logistics

  • Tech Stack: WeWeb (Frontend) + Supabase (Backend/Database).
  • Target Timeline: 7–14 days.
  • Contract Type: Fixed price.

:clipboard: 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.

:gear: Core Workflow & Features:

  1. 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.
  2. Unified, Responsive Score Screen: A single WeWeb page displaying a visual grid of active courts (e.g., Courts 1–4).
  3. 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.
  4. 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.
  5. 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)”).
  6. 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.”

:balance_scale: 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.

:envelope_with_arrow: 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.”

2

Club A’s players will never appear in Club B’s dropdown because I’ll use a proper Supabase database structure with strict club_id separation. Every player, session, and match will be linked to the correct club, with RLS policies to prevent cross-club data access.

Hi! I’m a WeWeb expert with strong Supabase/PostgreSQL experience. I can build this badminton score tracker with a clean, responsive UI for iPad and mobile, including QR-based access, Supabase Realtime, player ratings, fair-play queue sorting, and Present/Absent filtering.

I’ll also handle Supabase Auth for organizers, consent validation, privacy notice, and data minimisation. The public scoring flow will stay simple without requiring players to register or log in.

I understand the free-tier requirements and can target the 7–14 day timeline. Happy to discuss the details and get started!

3

Hi Charlie,

On your screening question: club data isolation would be enforced in the database itself, with row-level security keyed on the club, so one club can never read or write another club’s data, even through the API. GDPR is handled by design: consent checkbox, privacy notice, and only the data strictly needed for a session, nothing more. Scope as you described: organizer admin with Supabase auth, responsive scoreboard reachable by QR on iPad and mobile, live score entry, ratings from 1200 updated automatically, fair-play queue sorted by games played, presence toggle, all inside the free tiers and in your own accounts. I’ve sent you a message with the fixed quote and delivery plan so we can move forward directly.

Steve

4

I would link each player, session and match to its club in Supabase, then enforce access on the server so changing a club ID in the browser would not expose another roster. For players without accounts, I would use a limited session link that the organizer can revoke, with score submissions checked on the server. That would need testing with two separate clubs before rollout.

Are you still looking for help, and what budget and number of clubs and players are you planning for the prototype? I would start with a small paid milestone to prove club separation and score entry before committing to the full build. We can handle the details here in writing.

Isaiah

5

Club separation in Supabase: I would structure the database around a clubs table and ensure every club-specific record — including players, sessions, courts and matches — is linked to the appropriate club_id through foreign-key relationships. The WeWeb queries used for player dropdowns would always be scoped to the active club/session, while Supabase Row Level Security (RLS) policies would provide the backend enforcement so that data belonging to Club A cannot be retrieved through a Club B context. I would not rely on frontend filtering alone for data isolation.

Hi Charlie,

I’m very interested in this project because the WeWeb + Supabase architecture you have described is closely aligned with a platform I have recently been building.

My current project, AfriFarmWork, is a multi-user marketplace built with WeWeb and Supabase/PostgreSQL. I have been working hands-on with relational database design, Supabase Auth, Row Level Security policies, dynamic WeWeb collections, role-based views, filtered queries, database relationships and controlled frontend/backend workflows.

For example, AfriFarmWork separates farmers, workers, farms, jobs and applications through related database tables. I have implemented RLS rules so users can only perform actions against records they are authorised to access, rather than relying solely on WeWeb to hide data. This same principle would be important for your club_id separation.

For the badminton prototype, I would approach the core architecture approximately as:

  • clubs

  • organizers / authenticated club admins

  • players linked to club_id

  • sessions linked to club_id

  • session_players for presence and games-played counts

  • courts

  • matches / scores

  • persistent player ratings

Players would remain public/non-authenticated as requested. The QR/session link can carry a non-sensitive session identifier, which WeWeb uses to load only the relevant session and club data.

For the fair-play queue, I would query active/present players for the current session and order them by their session game count ascending, allowing WeWeb to display labels such as “John Doe (1 game)”. Absent players would be excluded from the available-player collection.

For Realtime, submitted match results can update Supabase and subscribed WeWeb views so that the central iPad reflects new scores without requiring a manual refresh.

I also understand your privacy requirement. The player table can be deliberately minimal — essentially player ID, club relationship, display name and rating — while session-specific information such as presence and game counts stays in the appropriate session relationship table. The consent requirement can be enforced before the organizer is permitted to save/import the roster.

I am comfortable working within the WeWeb and Supabase free-tier constraints, so I would design the prototype with those limits in mind rather than introducing unnecessary infrastructure.

I can also share examples of my current WeWeb/Supabase work and my LinkedIn profile, where I regularly document practical work around Supabase, WeWeb, database security and application logic: https://www.linkedin.com/in/emeka-obiaku/

The proposed 7–14 day prototype timeline is workable for this scope, subject to agreeing the final rating formula and precise admin workflow.

I would be happy to discuss the database schema and workflow before development begins.

Regards,

Emeka

6

Club separation would be enforced in the database and server-side access checks, not just by filtering a dropdown. Players, sessions and matches would belong to a club, with database constraints preventing cross-club relationships. Organiser access would be restricted by membership. For players without accounts, a revocable session token in the QR link would grant narrowly scoped access; changing a club ID would not grant access to another roster. I would test this with two clubs and attempts to cross their boundaries.

Hi Charlie — I’m interested in delivering this as a fixed-scope project. My background spans customer-facing platforms, systems integrations and responsibility for software delivery as Head of Software at Acorn Insurance.

I’d split delivery into two paid milestones: organiser setup, club isolation and live score entry first; then ratings, attendance, fair-play ordering and handover. Duplicate submissions and score corrections need explicit handling so ratings and game counts remain consistent.

WeWeb currently lists free publishing up to 1,000 sessions; Supabase also has usage limits and inactivity pausing, so I would size the pilot before promising zero ongoing costs.

Is the project still open? What budget have you allocated, how many clubs and concurrent players are expected, and have you chosen the rating formula? With those details I can provide a fixed quote and confirm whether the 7–14 day target is achievable.

Dave Butterworth

7

Happy to share how I’d approach this - I’m a full-stack developer (Postgres/Supabase + modern web) and this is exactly the shape of app I build: public-facing, no-account UX with organizer-only auth.

The Supabase side is where the real design lives, and I’d lock these decisions early:

**Signed session links** - the QR resolves to a public WeWeb page that filters by a signed session token in the URL (not a plain ID - signed, so nobody can guess or share another club’s session link). Score inserts go through Supabase REST with row-level-security policies scoped to that session, so anonymous access stays clean.

**Free-tier discipline** - append-only score events plus a computed view for current state, instead of live-updating player records. Fewer row operations on the free tier, and the fair-play queue becomes auditable from raw events: who queued when, who played when, no disputes.

**Fair-play queue** - a queue table keyed on club_id with enqueued_at / played_at timestamps; the rotation view sorts by wait time across available courts.

**Data protection** - player names only, no accounts, scanning the QR is the consent moment, and a club-level cascade delete covers erasure requests cleanly.

**Front end** - WeWeb responsive views for both the central iPad and phones, organizer panel behind Supabase Auth with club_id separation.

I quote fixed-price in three phases: (1) schema + club/organizer setup, (2) score logging + queue views, (3) polish + QR generation for printing. 7-14 days is realistic for the prototype scope you describe.

Portfolio: alaneisenberg.tech | GitHub: github.com/eisen0x