How rhythmees works under the hood
For club owners rather than developers: what the platform runs on, where the data is, how it is protected and how the demo differs from a live club.
How data flows
Phone or computer
member, parent, coach
Club website and portal
Vercel · Dublin
Club database
Supabase · EU
ČSTS and WDSF federations
competition results
E-mail and notifications
Resend, Web Push
Analysis
competition statistics, read-only
What rhythmees is made of
Each part is handled by an established service that specialises in one thing. The club does not have to set any of it up.
Website and phone app
Next.js and React, an installable web app (PWA)
One website is both the club's site and the members' portal. On a phone, members add it to their home screen and it works like an app: its own icon, full screen, notifications. Nothing to download from an app store.
Hosting
Vercel, servers in Dublin (EU)
The website runs in a cloud that scales on its own: when the whole club signs in at once before a training camp, nothing slows down. The club doesn't have to install or look after anything.
The club's database
Supabase (PostgreSQL), EU region
Members, lessons, payments and results are kept in a database each club has to itself from the day it signs the contract. One club's data never mixes with another's.
Sign-in
Supabase Auth
Members sign in with their e-mail and password, or with the link from their invitation. Passwords are only stored in an irreversibly encrypted form, so nobody can see them, not even the operator.
E-mails
Resend
Invitations, payment confirmations, lesson reminders and monthly summaries for parents are sent from the club's address. Lesson invitations go straight into the coach's phone calendar.
Phone notifications
Web Push
A new lesson request, an approval or a change of time arrives as a notification, just as it would from any other app. Coaches can approve a request straight from the notification.
Payments
QR payment (the Czech banking standard)
Members pay by bank transfer with a QR code in their banking app, and the money goes straight to the club's or coach's account. rhythmees never sees card numbers or bank logins.
Calendar
Calendar subscription (iCal)
Anyone can subscribe to lessons, training camps and competitions in their Google, Apple or Outlook calendar. Changes show up there on their own.
Competition results
Connected to ČSTS and WDSF
Members' results load every night from the federations' official systems. Nobody has to type them in by hand.
Analysis
Calculations in Python, a separate database of competition data
ELO, moving up a class, judges and forecasts are calculated from ČSTS results outside the clubs' databases. The portal only reads them; the calculations never reach the club's personal data.
Security and privacy
- Everyone sees only what they should
- Access rules are enforced by the database itself, not just the website. Members see their own lessons and payments, parents their child, coaches their calendar, and management the whole club.
- Encrypted connection
- All communication between the phone and the app goes over a secure connection (HTTPS), the same as online banking.
- Data in the European Union
- The website and the database run on servers in the EU. rhythmees follows the GDPR. The club reads the data; the operator only does so when handling a support request or a bug.
- Nightly backups
- A live club's database is backed up every night, and the backup is stored encrypted. If something goes wrong, the data can be restored.
In development and operation we follow the practices the ISO/IEC 27001 standard for information security management calls for: access control, encryption, backups, a record of changes and regular checks. We do not hold an ISO 27001 certificate, though.
Details on how personal data is processed are in the privacy policy.
Regular checks
It is not only a person keeping an eye on rhythmees. These checks run on their own and raise an alert when something is wrong.
Automated tests
on every change
Over 600 small tests check that payments, access, the calendar and calculations work correctly. If one fails, the change isn't released until it's fixed.
Website check
every day
A robot goes through every club's website the way a visitor would: is it up, does sign-in work, is the portal closed to outsiders, and do the pages have the right security settings.
Security check
every week
Makes sure no secret key or password has found its way into the code or onto the website, and goes through the recommendations for keeping the database secure.
Release safeguard
on every release
Before a new version goes live, it checks that the club's website talks only to the club's own database and that no secret keys reach the browser.
The demo and a live club
| This demo | A live club | |
|---|---|---|
| Data | Made up, reset to how it started every night | The club's real data |
| Database | One shared by all the sample clubs | The club's own database |
| Sign-in | By picking a role, no password | Each member's own account |
| E-mails | Not sent | Sent from the club's address |
| Address | demo.rhythmees.com | The club's own domain |
| Analysis | A sample with made-up names | Members' real results |
The code is the same in both: what you try here also works in a live club.
How new features are made
- The code of rhythmees is in a single repository on GitHub. Every club runs on the same code; they differ only in settings, look and which modules are switched on.
- Every change first goes through the automated tests and gets a test version of the website. Only after a check does it go live.
- Database changes are released as documented steps (migrations), the same way in every club, with checks that none of them deletes data.
- New features are switched on here in the demo first. They reach a live club once they work.