Gameya

PROBLEM

A gameya is a trust game: twenty people each pay a fixed amount every week and take turns collecting the pot. It normally runs on paper, memory, and a WhatsApp group, so the questions never stop — who paid this week, who is late, whose turn is next, how much exactly do I get? Members won't create accounts for a savings circle among relatives, and the organiser needs one place to record payments and keep an honest history.

WHAT'S IN IT

• +Before the PIN a visitor sees only a minimal summary — progress, weekly amount, payout per turn. After it: the full payment table, payout order, terms, and a form to message the organiser.
• +The payment table encodes paid, advance-paid, unpaid, and upcoming with shape as well as colour; a payout week shows an exact-amount tooltip, and a ×2 badge when one person collects twice the same week.
• +Unpaid is never stored — it is derived (no payment row and the week has started), so an advance payment is just rows for future weeks and the statuses cannot drift apart.
• +The admin side records payments and advance payments, assigns turns (a person can hold only as many turns as they have names, enforced on the server), tracks deliveries, sends WhatsApp reminders by link, shares the gameya by link and QR code, and keeps an audit log of every change.
• +Members can pay by InstaPay and send proof of the transfer from the gameya page: the payment details (username, phone, QR code, a pay link) are set per gameya, the proof image is compressed on the phone and stored in the database, and nothing counts as paid until the organiser approves it. Until then the week shows as pending.
• +A week's payment window runs Sunday to Thursday before the Saturday payout. A payment inside the window is on time; only one made before it counts as an advance, so the blue badge means what it says.
• +Lives inside an existing Supabase project in its own schema, behind its own restricted database role — verified on a simulated shared database that it cannot touch, or be touched by, the other apps' tables.
• +A first-visit guided tour, an animated hero, light and dark themes, and full reduced-motion support, on an interface designed for phones first.

ROLE

Solo builder — product design, data model, access control, the Arabic/RTL interface, the admin tools, the test suite, and deployment.

NOTABLE DECISION

No member accounts at all. Each gameya has a 6-digit PIN, stored only as a bcrypt hash and rate-limited to five wrong tries per device per fifteen minutes; a correct PIN sets a signed, httpOnly cookie for that one gameya. Every database read happens on the server, row-level security is on with no policies so the database's public API sees nothing, and the page loads no member names until the cookie proves access. The result: the simplest possible experience for relatives, with the access control kept where it can actually be tested.