GymSchool · Athletic directors, coaches & parents · Early access · 2026

School athletics on one platform — consent-gated records the school owns, publishing outputs the school keeps

Most schools still run their athletics programme from a combination of email, spreadsheets, and apps that do not talk to each other. GymSchool is the platform where those records live together: the consent ledger that decides which athletes appear on published pages, the schedule and results engine that keeps the season record current, and the publishing layer that turns those records into a game-night playbill, a seasonal programme, a team record book, and a yearbook section — outputs the school keeps permanently, not data that leaves with a vendor. Early access — no pricing commitment, no signup, no live payments today.

Book a conversation How it works

Consent-enforcedunconsented athletes appear nowhere — enforced at the engine, not by a checklist

School-ownedevery record, every season — never expires, never leaves without you

Real outputsgame-night playbill, seasonal programme, record book, yearbook section — from the same records

No surveillanceno live biometric feeds, no GPS tracking, no fitness data, no secondary markets; face matching is a separate per-athlete opt-in, off by default

The publishing asset — what the records become

The same data that schedules games and tracks results becomes the record book, the playbill, and the yearbook section

An athletic director enters a schedule. A coach enters a roster. A scorekeeper enters results. In most schools that data lives in three places and never becomes anything more than what it was entered as. In GymSchool, the same records the coach uses to manage eligibility and attendance are the records the publishing engine uses to generate a game-night playbill, a seasonal programme for distribution, a graduating senior’s career stat page, and a structured yearbook section export that drops into the school’s layout without re-entry.

Every output respects the consent gate: an athlete who has not opted in does not appear in any published format, regardless of who initiates the export or what output format is chosen. The consent check is not a step someone can accidentally skip — it is applied by the engine on every output, every time. The school keeps the published record permanently. It does not expire when a vendor contract ends.

The consent/depiction ledger, schedule and results pages, and the publishing engine are built and production-ready. Live in-game scoring and the coach game-planning UI are in active development. The charge rail that moves money is honest-off — not enabled for live transactions today.

Book a conversation Full platform

How it works

The athletic season in four stages

GymSchool runs on a season rhythm: consent collection and roster setup before the season, schedule publication and first game results at the opener, stats and publishing mid-season, and a record book and yearbook export at year-end. Every stage is described as it is built today.

Step 1 · Pre-season — sport setup and consent collection

The athletic director configures sports for the year: roster imports, consent collection, season schedules, and publishing permissions per sport. Each athlete’s depiction consent status is collected before the first game. Guardians opt in; athletes who do not opt in are enrolled in the programme for all operational purposes — attendance, eligibility, emergency contacts — but do not appear on any published page or print export. The school owns the roster and consent records from day one. Consent collection and roster management are built and production-ready.

Step 2 · Season opener — schedule publication and first results

The season schedule goes live on the published schedule page as soon as it is configured and reviewed. The first game results are entered by the coach or AD; the results page updates immediately. A game-night playbill can be generated from the consent-gated starting lineup — names and positions of athletes who have opted in, in the order the coach sets. Sport-specific stat categories are configured at season setup so post-game stats are ready to enter from the first event. The schedule page, results page, and game-night playbill are built and production-ready.

Step 3 · Mid-season — results, stats, and publishing rhythm

Coaches enter post-game stats; the season record updates in the roster and publishing engine automatically. The athletic program — a mid-season edition with current standings, rosters, and upcoming schedule — is generated on demand for print or digital distribution. Achievement recognition (season leaders, milestone achievements) draws from the consent-gated roster and is adviser-reviewed before it is published anywhere. Live in-game scoring and the real-time spectator dashboard are in active development for this stage. Post-game stat entry and mid-season publishing are available today.

Step 4 · Year-end — record book, yearbook integration, and season archive

The year-end record book compiles full season stats, final standings, and roster bios for every consented athlete into a structured export. The yearbook section export drops the season data directly into the school’s yearbook layout without re-entry. The school’s athletic archive grows by one season and remains school-owned permanently — accessible to the next AD, the next coach, and the next class of athletes. One-click export is available in writing: if the school ever leaves the platform, every record leaves with it. Year-end publishing and archive are built and production-ready.

The full platform

Five engines — honest about what is built and what is coming

Every feature is labelled honestly: Built means the underlying engine is production-ready. Early access means the data model exists and the live surface is in active development. We do not claim otherwise.

Schedule and results pages — the school’s public record of every season

The schedule engine publishes event dates, opponents, locations, and results against a per-sport season configuration. Results pages show final scores and season records. Every published page respects the consent gate: an unconsented athlete is absent from the roster listing on the page, not redacted with a placeholder — their name simply does not appear. Coaches update results; the athletic director controls what is published. The school owns the published record permanently — it does not expire when a subscription lapses. Schedule publishing and results pages are built and production-ready.

Schedule & results pages built · production-ready

Athletic publishing — programme, playbill, record book, and yearbook integration

The publishing engine turns consented athletic records into real print and digital assets: a seasonal athletic program with sport-by-sport rosters and schedules, a game-night playbill with starting lineups and senior bios, a team record book with season-by-season history, and a yearbook section export that drops directly into the school’s yearbook layout. Every output respects the consent gate — an unconsented athlete does not appear in any export regardless of format. Programme, playbill, and record book content is adviser-reviewed before publish. Parent and family storefront commerce for print products is on the built cart substrate; the checkout that accepts payment is honest-off. The publishing engine is built and production-ready.

Publishing engine built · print commerce honest-off

Live stat-entry and scoring — in-game capture and season records

The stat data model is built: sport-specific stat categories, per-athlete per-game records, season aggregates, and career totals. The live capture surface — the in-game scoring interface a scorekeeper uses on a phone or tablet at the scorer’s table — is in active development. In the current early-access state, stats can be entered post-game by a coach or administrator and the season records are reflected immediately in the roster and publishing engine outputs. The real-time scoring dashboard that broadcasts a live score to spectators is also in active development. Live stat-entry and real-time scoring are early-access; post-game stat entry is available today.

Stat model built · live capture early-access

Coach game-planning — depth charts, practice plans, and scouting

The game-planning layer gives coaches a structured workspace inside the same platform that holds their roster and stats: depth charts built from the consent-gated roster, practice-plan templates tied to the season calendar, and an opponent scouting board. The depth chart automatically excludes athletes without depiction consent from any shareable export. Game-planning tools are early-access: the data model and roster linkages are built; the coach-facing UI surface is in active development. Athlete data from the game-planning layer is never shared with outside analytics services, never indexed by search engines, and never used for any purpose beyond the school’s own coaching and administrative work.

Data model built · coach UI early-access

Who it serves

Three distinct tracks — athletic director, coach, and parent — one platform

Athletic directors

The AD configures sports, imports rosters, and owns the consent ledger. They control what is published and what stays internal. The consent gate is the AD’s tool: an athlete without a completed consent form does not appear on any published output regardless of what a coach or parent requests. The AD has a full view of every sport’s season status, consent coverage, and publishing history in one administrative view. Year-end they run the record book compilation and yearbook section export. The complete administrative view is built and production-ready.

Coaches

The coach enters results, updates stats, and manages the depth chart for their sport. Post-game stat entry is available today; live in-game capture is early-access. The game-night playbill is generated from the coach’s starting lineup — the consent gate enforces itself so the coach does not carry the burden of checking each athlete’s consent status before handing the playbill to the print service. The game-planning workspace — depth charts, practice plans, scouting board — is early-access: the data model and roster linkages are built, the UI is in development.

Parents and boosters

A parent can read the schedule and results pages without creating an account. They see only consented athletes — which means a parent whose child has not opted in will not find their child’s name on a public page, because it is not there. A booster who wants the seasonal programme or a copy of the record book can order a print product through the parent storefront; the storefront commerce infrastructure is on the built cart substrate, with the checkout honest-off until the charge rail is enabled.

A school athletics platform — not a fitness-surveillance feed

The school’s athletic records stay with the school. No biometrics, no GPS, no secondary markets.

GymSchool records what a school has always recorded: roster information, game schedules, final scores, and sport-specific statistics entered by a scorekeeper or coach. There is no biometric data collection, no GPS location tracking, no heart-rate or wearable API, and no fitness-surveillance feed. This is an explicit architectural decision — not a gap waiting to be filled.

Athlete records are never sold to recruiting services, talent-identification platforms, or sports analytics companies. The data model is built for a school’s own operational and publishing needs: scheduling, eligibility, consent tracking, results, and the publishing outputs the school uses to celebrate its athletes every season. Nothing leaves the platform except what the school initiates — an export the AD runs, a playbill the coach generates, a yearbook section the adviser approves.

Athlete consent & school data ownership

Consent-gated, school-owned, permanent. The records stay with the school.

Every athlete’s depiction consent status is collected from their guardian before the first published output of the season. An athlete without a completed opt-in does not appear on any published page, any print export, or any yearbook section — enforced by the engine. Consent is not assumed. It is collected, logged, and revocable at any time. A revocation removes the athlete from all future publishing immediately and is recorded in the ledger.

The school owns every record in the platform. Rosters, consent records, season data, stats, and publishing history belong to the school — not to GymSchool. No athlete or student data is sold, licensed, or shared with outside companies. One-click export is available in writing: if the school ever leaves the platform, every record leaves with it. The school’s athletic archive does not expire when a contract ends.

What is built and what is coming — plainly

The consent ledger, scheduling, results, and publishing are built. Live scoring and game-planning are in active development.

Built and production-ready today: the consent/depiction ledger (guardian opt-in, revocable, logged, enforced on every output); roster management (import, emergency contacts, eligibility flags, consent status); schedule and results pages (season config, opponent, score, season record, consent-gated roster); the publishing engine (seasonal programme, game-night playbill, team record book, yearbook section export); the cart substrate and catalog for print commerce; and the stat data model (post-game stat entry, season aggregates, career totals).

In active development: the live in-game scoring interface (in-game stat capture at the scorer’s table); the real-time scoring dashboard for spectators; and the coach game-planning UI (depth charts, practice plans, scouting board, play diagrams). The charge rail — the part of the platform that moves money — is honest-off: present in the platform, not enabled for live transactions. There is no live checkout, no billing, and no subscription. We say so directly because athletic directors deserve to know what is production-ready and what is still being built.

Connected to the school platform

GymSchool captures the season. Assembly captures the night. Seen puts every athlete on a page. The booster club runs the gate.

GymSchool manages the schedule, the roster, the records, and the publishing output. Assembly is the moment layer: live school events captured, ticketed, and archived — the Friday night game, the championship match, the senior night. A GymSchool event and an Assembly event are the same night; wiring them together is natural. Seen is the recognition layer: the programme that ensures every student athlete lands on a real page in the yearbook, the newspaper, or the seasonal programme — adviser-approved and consent-verified. School Booster Network runs the booster club: gate-scan at the entrance, concessions at the stand, and the no-skim fundraiser split for the athletics booster. All four platforms share the same consent-first architecture and the same school-owned data promise.

assembly.school seen.school schoolbooster.network homeroom.software

Early access · Athletic directors, heads of school, coaches

Book a conversation to see the current state honestly

GymSchool is in active development. We do conversations that show the current state honestly: how the consent ledger works for a roster of 200 athletes across eight sports, how the schedule and results pages enforce the consent gate, how the publishing engine generates a game-night playbill and a yearbook section export, and what post-game stat entry looks like today versus what live in-game scoring looks like in development. There is no pricing commitment and no signup. If it looks right for your programme, we discuss what early access looks like.

To book: email [email protected].

FAQ

Common questions

What does “consent-gated publishing” mean in practice?

Every athlete on the platform has a depiction consent status set by their guardian. When the platform publishes anything — a schedule page, a results listing, a game-night playbill, a record book, a yearbook section — it checks each athlete’s consent status. An athlete who has not opted in does not appear in the output. This is not a filter applied by a coach before they hit publish; it is enforced by the engine on every output regardless of who initiates it. A revocation — a guardian withdrawing consent — removes the athlete from all future publishing immediately and is logged in the consent ledger.

Is the school’s data actually owned by the school, or does it belong to the platform?

The school owns its athletic records. The roster, the consent ledger, the season schedules, the results, the stats, and the publishing outputs belong to the school — not to GymSchool. One-click export is available in writing: if the school ever leaves the platform, every record leaves with it in a portable format. The school’s athletic archive does not expire when a subscription ends; the export is always available. GymSchool does not sell, licence, or share athletic data with outside analytics services, advertisers, or recruiting platforms. There is no secondary market for athlete records, and there is no fitness-surveillance feed.

What athletic publishing outputs does the platform produce?

The publishing engine produces four types of output, all from the same consent-gated records: a seasonal athletic program (sport-by-sport rosters, schedules, and season preview, formatted for print or digital distribution); a game-night playbill (starting lineup, senior bios, sponsor slots); a team record book (season-by-season history, career stats for graduating seniors, school records by sport); and a yearbook section export (structured data that drops into the school’s yearbook layout without re-entry). Every output respects the consent gate. Adviser review is required before publication. The publishing engine is built and production-ready.

Who can see the schedule, results, and roster pages?

Schedule and results pages — dates, opponents, scores, season records — are publishable to any visitor without requiring a login. Roster listings on those pages show only consented athletes. A parent or grandparent can read the results page without creating an account. Detailed athlete profiles, stat breakdowns, and the full consent ledger are accessible only to the athletic director and coaches inside the authenticated administrative view. There is no public searchable roster of minor athletes. No athlete data is indexed by search engines beyond what the school explicitly chooses to publish on its schedule and results pages.

How does live scoring and stat-entry work? What is available now?

The stat data model is built: sport-specific stat categories, per-athlete per-game records, season aggregates, and career totals are all in the platform. Right now, stats are entered post-game by a coach or administrator, and the season records update immediately in the roster and publishing engine outputs. The live capture surface — the in-game scoring interface used at the scorer’s table — is in active development and is early-access. The real-time scoring dashboard that broadcasts a live score to spectators is also in active development. Post-game stat entry is available today; live in-game capture is early-access.

What are the coach game-planning tools?

The game-planning layer gives coaches a structured workspace inside the same platform that holds their roster and stats: depth charts built from the consent-gated roster, practice-plan templates tied to the season calendar, and an opponent scouting board. The depth chart automatically excludes unconsented athletes from any shareable export. The game-planning tools are early-access: the data model and roster linkages are built; the coach-facing UI surface is in active development. No athlete data from the game-planning layer is shared with outside analytics services.

How is this different from a spreadsheet and email?

The practical difference is the consent gate, the publishing engine, and the school-owned archive — none of which a spreadsheet provides. A spreadsheet does not enforce which athletes appear on a published page based on consent status. It does not generate a print-ready athletic program or yearbook export from the same records a coach uses for scheduling. And a spreadsheet belongs to whoever last saved it, not to the school. GymSchool gives the athletic director a single record for every athlete — consent status, emergency contacts, eligibility, stats, publishing history — that stays with the school permanently and produces real outputs every season.

How does the yearbook integration work?

The yearbook section export produces structured season data — team photos organised by consent status, roster bios, season statistics, final standings, award recipients — in a format that drops directly into the school’s yearbook layout via the publishing platform. There is no re-entry: the data the coach enters for scheduling and the data the AD enters for results is the same data that appears in the yearbook section. The export respects the consent gate, so an unconsented athlete does not appear in the yearbook section regardless of whether the yearbook editor remembers to remove them. The yearbook integration is built and production-ready.

Does the platform track athlete biometrics, GPS, or fitness data?

No. GymSchool does not collect, store, or process biometric data, GPS location, heart-rate or wearable data, or any fitness-surveillance feed from athlete devices. The platform records what a school has always recorded on a roster: name, sport, position, game statistics that a scorekeeper enters, and consent status. There is no fitness-tracking integration, no wearable API, and no secondary market for athlete performance data. This is an explicit architectural choice — not a gap in a roadmap.

What does pricing look like?

GymSchool is in active development. The charge rail — the part of the platform that processes payments — is not yet enabled for live transactions. There is no live pricing, no billing, and no subscription today. When the charge rail is enabled (a founder-gated decision), pricing will be published transparently here. The model is a per-school SaaS fee based on active athletes, with a transparent payment margin on print commerce and no skim on school-run fundraising. We will say what it costs before asking a school to commit to anything. The best next step is a conversation: we show the current state honestly and discuss what early access looks like for your programme.

What can we actually use right now?

In a demo we walk through the current state honestly: configuring a sport with a roster import and consent collection; publishing a season schedule and results page with the consent gate enforced; generating a game-night playbill from a starting lineup; entering post-game stats and seeing the season record update; and generating a record-book and yearbook section export. None of those involve live payments today. Live in-game scoring and the coach game-planning UI are in active development. A conversation is the honest next step — we show what is built, what the development timeline looks like, and what early access means for your programme.