Playbook holds two things worth protecting: a coaching staff's game plan, and the names of their players. This page describes how each is kept where it belongs. It describes what is actually built, not what is aspired to.
Teams are separated in the database, not the app
The usual way software keeps one customer's data from another is to remember to filter every query. Miss one and you have a breach. Playbook does it a layer lower: every table carries row-level security policies in Postgres itself, so the database refuses to return one team's plays to another team's coach even if the application asks it to wrongly.
That is not a claim we make on trust. The test suite runs the real migrations against a real Postgres engine and then tries the attacks — reading another team's plays, writing to a team you were removed from, promoting yourself to an administrator — and asserts each one fails. Those tests run on every change.
Players are a separate account type, not a coach with fewer buttons
A player account is built from its own policies rather than by carving exceptions out of a coach's. It can reach exactly two things: the plays a coach has explicitly installed for players, and that player's own results. Call sheets, practice scripts, scouting reports, the engagement dashboard, and every other player's quiz history are not merely hidden from the interface — the database will not return them.
Coach-authored quiz answer keys never reach the browser at all. Quizzes are graded on the server, against a column players have no read access to, so the answers cannot be pulled out of the page.
There is no messaging, by design
Playbook has no chat, no direct messages, no comments, and no compose box anywhere — between coaches and players or between players. This is the single most common risk in youth-sports software and we removed it by not building it. Coaches push one-way alerts referencing content they already own; players may view, acknowledge, and react from a fixed set. Nothing freeform can be sent to a minor through this app.
Accounts and access
- Passwords are stored as salted hashes by our authentication provider. Nobody here can read one, including us.
- Password rules are enforced at the authentication service, not just in the sign-up form, so they cannot be bypassed by calling the API directly.
- Sign-in, sign-up, and invitation pages are rate limited per IP address to blunt credential stuffing and invite-link abuse.
- Coach access is role-based — owner, coordinator, coach, viewer — and a viewer genuinely cannot write, at the database level.
- Player accounts exist only by coach invitation. There is no self-serve player sign-up.
Data in transit and at rest
All traffic is served over HTTPS. Data is stored with Supabase and Vercel, which encrypt data at rest on their infrastructure. Recorded audio and video clips live in a private storage bucket and are served only through short-lived signed links, so a URL that leaks stops working.
Payments
Stripe processes every payment. Card numbers never touch our servers and we never receive them — we store only Stripe's customer and subscription identifiers, your plan, and its status. Incoming messages from Stripe are cryptographically signature-verified before they are acted on; an unsigned or altered one is rejected outright.
Who else can see your data
A short list of infrastructure vendors, named in full in our privacy policy: Supabase, Vercel, Stripe, Sentry, Upstash, and Resend. No advertisers, no data brokers, no analytics companies. Your plays are not used to train anything.
What we do not claim
We are a small operation and would rather be exact than impressive. Playbook does not currently hold a SOC 2 or ISO certification, has not had a third-party penetration test, and does not offer a contractual uptime guarantee. If your district requires any of those, tell us where you are in the process and we will be straight with you about what we can and cannot sign.
Reporting a problem
If you think you have found a vulnerability, write to support@playbook.example with enough detail to reproduce it. We will not pursue anyone who reports a genuine issue in good faith and gives us reasonable time to fix it before making it public.