Consent, not compliance: how member data should actually work

Most consumer software treats privacy as a compliance cost: the minimum disclosure required to avoid a fine, buried in a settings page nobody visits. For a running club, that's the wrong frame entirely — the data in question is often genuinely sensitive (health metrics, location patterns, contact details for minors in youth programs) and it's being handled by a volunteer organizer, not a corporate data team with a legal department.

What "scoped consent" actually means in practice

Rather than one blanket privacy policy a member agrees to once and forgets, the right model is a small number of independently revocable scopes: does the club see your weekly mileage? Your PRs? Your contact email for sponsor offers? Each scope is a separate, visible toggle a member controls at any time — not a single all-or-nothing agreement.

• Activity summary (weekly km, PRs) — off by default; a member opts in if they want the club to see their training trend.
• Contact sharing for sponsor perks — separate from event communications, so a discount code offer doesn't require handing over the same access as a race-day reminder.
• Health-scope data (if collected at all) never flows through the general API — it's architecturally separated, not just policy-separated.

Why this is a moat, not just a compliance line item

A club that can honestly tell members 'you control exactly what we see, scope by scope' earns a level of trust that a generic events platform never has a reason to build, because ticketing software doesn't need an ongoing relationship with the attendee. A community operating system does — and the consent model is what makes that relationship durable instead of extractive.

This is also, bluntly, a defensibility argument: a consented data layer that members actively trust is hard for a competitor to copy by just shipping a similar feature list, because trust is earned over time, not deployed in a sprint.