The context
An amateur club — football, dance, judo, music, swimming — runs on a spreadsheet, a paper folder and a chat group. It works, at the cost of a great deal of volunteer labour: chasing fees by hand, answering the same question about timings twenty times over, rebuilding the attendance list every season.
Navito is our answer: one platform carrying the club, the families and the children.
The challenge
The product has three sides, not two, and that is where everything is decided.
The volunteer officer uses the tool in the evening, on a computer, with no training, and may hand over next year. What they leave behind has to stay readable by their successor.
The coach is standing in a gym or on a touchline, often with no network, sometimes wearing gloves. Their sessions last under a minute. If marking attendance takes longer than the paper sheet it replaced, they will not mark it — and software the field works around produces no reliable data at all.
The parent opens the app in the car and always asks the same four questions: when is it, where is it, were they there, have I paid. And their children are not necessarily in the same club.
The child, finally, is a user in their own right — but you cannot ask them for an email address and a password, nor collect their data to identify them.
What we did
- A Django API partitioned by club at row level, carrying members, groups, the schedule, attendance, communication and fees.
- Child access with no email and no password, through a physical access card handed out by the club — a short code and a QR in player-card format. Nobody offers this, because nobody has solved authenticating a child without collecting their data.
- An explicit visibility matrix, letting a parent see their child’s group without ever seeing the other children’s data.
- Attendance that works offline. The coach writes a dated, signed intent; the sheet everyone reads is the recomputed result of those writes. Nothing is overwritten: when two coaches disagree, the losing mark stays, flagged as superseded, and the disagreement is a readable line rather than a silent rule.
- One parent account valid across every club their children belong to: the app is navigated by child, never by club.
- Collecting membership fees on the club’s behalf, with the identification duties that entails.
- Three interfaces on one visual language — the club’s web tool, the family and field mobile apps — fed by the same design tokens, compiled once per platform.
The outcome
The platform is in production, with a first club. That is the crossing that counts: a product proves nothing until a real organisation has started using it for real.
What this product gives us goes beyond its own market. Offline attendance in particular forced us to treat properly a problem most field applications treat badly: a phone clock can lie, a sync queue can be replayed twice, and a write that fails silently is worse than an error message. Those reflexes serve anywhere the network is missing.
