Bynle

Client

React, with React Router guarding private routes and a separate route tree for scanner accounts.

Application

Django REST views grouped into ten domain handlers, with serializers for validation and JSON conversion.

Data

PostgreSQL for structured data, running from a Docker image; an S3 bucket for uploaded media.

Integration

Stripe for payments and Connect onboarding, with a status check deciding whether a club or user may charge.

Deployment

Railway for the backend and database, AWS Amplify for the frontend, Git-based version control for both.

Testing ran on three tracks: code review on every merge request, unit tests for the backend, and user testing sessions with real students.

The backend finished with 134 unit tests across models and views — data integrity and validation rules on one side, request handling and business logic on the other, including permission checks such as confirming that only a scanner account can reach the ticket validation endpoint. No change reached the main branch without review by the other of us.

User testing changed the product. Two requests came back clearly enough that we built them:

• A notification bell. Users wanted friend requests and incoming transfers reachable from anywhere rather than by navigating to the page that held them. A bell went into the navbar, with a count.
• Deleting a sent transfer. Participants wanted to withdraw a transfer sent by mistake, or after a change of plan. Sent transfers became deletable.

What broke

1. 01

   Club admins modelled as their own class

   Problem

   Club administrators started as a dedicated model class. It was the wrong shape: the relationship between users and clubs is many-to-many, and forcing it through a class of its own made administration awkward.

   Fix

   Refactored to a many-to-many relationship, which let several users administer several clubs without ceremony and simplified the whole administration path.

2. 02

   Two people, deleted migrations, one broken database

   Problem

   Early on we were both working in separate branches and both generating migrations as we changed the models. Neither of us understood Django migrations well enough, and we had both deleted some. Rebasing to merge into main broke the database: it no longer matched the models, and it took a long time to work out why.

   Fix

   We agreed never to delete a migration again unless the database was backed up and a full wipe was genuinely warranted. A script that repopulated the database from scratch meant we could rebuild a working dataset quickly while we sorted it out.

3. 03

   Tickets stayed valid mid-transfer

   Problem

   While a transfer was in progress the ticket remained active, which risked unauthorised entry on a ticket that was already being given away.

   Fix

   Tickets hold a transfer state until the recipient accepts or the sender cancels. In that state the ticket cannot be scanned and counts as invalid at the door.

4. 04

   Deploying three moving parts

   Problem

   Getting the Django backend, the React frontend and the database deployed together took days of reading documentation and a long run of failed attempts on the backend server.

   Fix

   Railway, which integrates with the repository and pulls the latest version of a fixed branch, brought the backend and the database up in one shared instance; the frontend went to AWS Amplify.