FrostleteFrostlete
A structural truth

One jersey.
Seven clubs.

A rugby club isn't a team. It's a youth academy, a senior setup, a social club, a compliance body, a parents' engine, a small business, and often a charity — all pretending to be one thing.

Most software treats it as one. Frostlete treats it as seven.

§ I — The anatomy

The seven organisations you are actually running.

Each one has its own members, its own money, its own rules, its own failure modes. A rugby club is, structurally, a small federation. Pretending otherwise is what makes it so hard to manage.

I

The youth academy

Forty U6s to a dozen colts

Parents, guardians, consent forms, age-grade eligibility, the Wednesday training roster nobody wants to build.

II

The senior squads

1st XV, 2s, women's, vets

Overlapping selection pools. The hooker who plays 2s but covers 1s. The 40-year-old who retired last season and then didn't.

III

The social club

The bar, the tours, the dinners

A whole parallel institution with its own money, its own rules, and a membership list that doesn't quite match the playing one.

IV

The compliance body

DBS, GDPR, safeguarding

The governance layer most clubs discover only when something goes wrong. Policies, consents, incident logs, audit trails.

V

The parents' committee

Drivers, bake sales, volunteers

The engine of every junior section. Half the workforce of every club. Almost never on the org chart.

VI

The commercial entity

Sponsors, kit, grounds, contracts

A small business running a brand, a venue, a supplier chain, and half a dozen partnership agreements in various states of repair.

VII

The charity

CASC, community trust, grants

Many UK and EU clubs are registered charities. Which means members, donors, restricted funds, and a regulator who would like a word.

§ II — The overlap

One person. Many hats.

The seven organisations don't have seven separate populations. They share people. Software that makes you create a new account for every hat isn't helping — it's just moving the mess into a database.

Case 01

The playing coach.

On the sheet as a 2nd XV back row. On the team page as a U16s assistant coach. In the committee minutes as safeguarding officer. Three roles, three permission sets, one person — and the software treats them as one record with three hats, not three duplicated logins.

Case 02

The parent who coaches.

Guardian-consenting for their own U12 child. Coaching the U14s (so: access to another family's data, conditional on DBS and appointment). Playing vets on Saturdays. Three entirely different consent and access postures, all auditable.

Case 03

The committee treasurer who also plays.

Club-wide financial permissions. Team-scoped player membership. The permission tier system means one of those can change without disturbing the other. When they stand down as treasurer, they don't lose their place on the 3s.

§ III — The consent model

Seven organisations, one consent model that holds.

The reason most club software falls over isn't features. It's that it can't model who's allowed to see what, when the "who" has multiple roles and the "what" is sometimes health data about a minor.

Minors & guardians

  • Guardian links for every player under 18, with relationship type and verified status.
  • Per-category consent: health data, messaging, photos, development tracking, analytics.
  • Versioned consent records — a re-consent in 2027 doesn't overwrite what a parent agreed to in 2024.

Staff & delegation

  • Six built-in role tiers from player to owner, plus unlimited custom roles a club invents.
  • Granular permission namespaces: health data, events, messaging, roster, discipline — each with view / edit / create.
  • Delegation is tier-limited — admins can only grant what they themselves have. No accidental privilege escalation.

Member privacy

  • Each member controls 'share contact with club' independently of membership.
  • Row-level security at the database — access is enforced in the data layer, not just the UI.
  • Every join — via invite link, QR code, or approval — is logged, timestamped, and revocable.
The thesis

Your software should match the shape of your club — not the other way around.

The reason Frostlete feels different is that it was designed to the seven, not to a single tidy team. Every feature on this site exists because one of those seven needed it — not because a roadmap said so.

Software for a club, not a team.

Founding clubs are shaping what ships. Get on the list and help design it.