Founding Partner Program

A short reference for what the founding-league and founding-member flags mean, what they grant, and where the badges show up in the product.

What it is

The founding program is a small, capped recognition track for the earliest leagues that committed to running on Racey. It exists for two reasons:

1. To thank the people who showed up before the platform was finished.
2. To put a permanent, visible marker on those leagues and their primary admin so other users can see the program exists.

The cap is hard-coded at 5 founding members (MAX_FOUNDING_MEMBERS in packages/pricing/src/index.ts). The grant API rejects an attempted grant once the user count hits 5 with 409 FOUNDING_MEMBER_LIMIT_REACHED. Existing founding members can be re-granted (the cap check is skipped on idempotent re-grants), but new entrants are blocked once the slots are full.

As of the May 2026 production audit, 1 of 5 founding-member slots are filled and 5 founding leagues are flagged. The seat ratio is 1:5 because a single founding member's account can be associated with multiple founding leagues. Founding-league flags are granted alongside the user grant — see "Who qualifies" below.

The public founding-league application window is closed. The admin API still enforces the hard cap at the founding-member level, so any future exception is an internal platform-admin operation rather than a public application path.

Who qualifies

Founding-member status is granted only by a platform admin. There is no self-serve path, no application form, and no public criteria. The decision is made off-platform and applied through the admin UI at /admin or by direct API call.

The grant flow lives at POST /api/admin/founding-members (see apps/web/src/app/api/admin/founding-members/route.ts) and requires platform.admin permission. A single grant call takes both a userId and a leagueId and applies three changes in one transaction:

1. Sets User.isFoundingMember = true on the named user.
2. Sets League.isFoundingLeague = true on the named league.
3. Creates or upgrades a Subscription row for that user+league pair to plan: 'enterprise', status: 'active', currentPeriodEnd: null — i.e. perpetual Enterprise with no expiry.

After the transaction, any active paid Stripe subscriptions on the user's account are auto-cancelled to prevent double-billing. This is a one-way cleanup — the cancellation runs through the Stripe API and the local subscription rows are flipped to cancelled.

Revocation lives at DELETE /api/admin/founding-members and reverses the three transactional flips (user flag, league flag, subscription back to free). Stripe cancellations from the original grant are not auto-restored on revoke; the user would need to re-subscribe through the normal flow.

What founding members get

Enterprise tier features, free, forever, on the leagues they admin.

The mechanism is not "the user gets Enterprise" — the mechanism is "the user's leagues get treated as Enterprise regardless of their plan field." All runtime tier checks short-circuit when a league has isFoundingLeague = true:

• tier-context.tsx (lines 60–76) — canUse(feature) returns true unconditionally, isAtLimit() returns false unconditionally, and getLimit(key) returns -1 (unlimited) for any limit key.
• The league-admin sidebar in admin-layout.tsx skips all plan-gate badges (bypassGates = isPlatformAdmin || isFoundingLeague) so Enterprise-only nav items render as if you were on Enterprise.
• getLimit returning -1 means founding leagues get unlimited storage, unlimited drivers, unlimited seasons, unlimited everything that has a numeric cap on Free or Pro.

Founding member status (User.isFoundingMember) does NOT, by itself, automatically promote the user's leagues. The promotion happens because the grant API also flips isFoundingLeague on the named league in the same transaction. If a founding member creates a new league after their grant, that league starts on the founding member's plan tier (whatever their personal subscription says — typically free) and is NOT auto-flagged. A platform admin would need to grant founding-league status separately on the new league for it to inherit Enterprise behavior.

In practice this matters less than it sounds, because (a) founding members usually run one or two specific leagues that were named in the original grant, and (b) a platform admin can re-run the grant API on any new league with the same user.

The badges

Two badge components ship in the app, visually consistent and both styled in the same amber/gold pill:

• Founding Member (<FoundingBadge />) — a small amber/gold pill with a Shield icon and the text "Founding Member". Renders on users with User.isFoundingMember = true. Source: apps/web/src/components/founding-badge.tsx.
• Founding League (<FoundingLeagueBadge />) — same amber/gold pill, but with a Trophy icon and the text "Founding League". Renders on leagues with League.isFoundingLeague = true. Source: apps/web/src/components/founding-league-badge.tsx.

Both come in two sizes:

• size="sm" — compact inline pill, used next to names in lists, cards, table rows.
• size="md" — slightly larger pill, used next to page-header titles.

Both are theme-safe (light + dark) and use the same gradient + border treatment, so when the two appear on the same page they read as a matched set.

Where they appear

Founding League badge:

• Public league directory cards at /leagues — badge appears in the meta-badge row on each league card.
• Public league detail page header at /leagues/[slug] — md badge next to the league name.
• League admin sidebar at /league/[slug]/* — sm badge under the "League Admin" subtitle.
• Driver dashboard "My Leagues" page at /my-leagues — sm badge in each league card title (covers both Racing-In and Managing sections, plus the Archived collapsed section).

Founding Member badge:

• Public driver profile at /drivers/[id] — md badge next to the display name in the page header.
• Public drivers directory at /drivers — sm badge next to the driver name on each card.
• League admin Roster page at /league/[slug]/roster — sm badge next to the driver name in both the desktop table view and the mobile card view.

Surfaces that intentionally do NOT show the badges:

• Form fields, settings panels, destructive-action confirmations, and other "active-action" surfaces. The principle is: discovery / browsing surfaces show badges; doing-work surfaces do not.

What it's not

• Not a refund. Founding status does not retroactively refund any prior Pro subscription payments. The auto-cancel of active Stripe subscriptions on grant prevents future double-billing, but past charges stay charged.
• Not transferable. The isFoundingMember flag lives on a User row, not on an account holder identity. There is no built-in mechanism to move the flag to a new account if the user creates a new login. A platform admin could revoke + re-grant manually, but this is an off-platform decision.
• Not visible to billing. A founding member's subscription rows are real Stripe subscriptions only when they were paying before the grant; afterwards their league's behavior is driven by the isFoundingLeague flag, not by Stripe. The billing page on a founding league still shows the Subscription row (plan: enterprise, status: active, currentPeriodEnd: null) so the state is auditable, but no invoices are issued.
• Not retroactive on new leagues. As noted under "What founding members get," founding-member status does NOT auto-flag any new leagues the user creates after the original grant. Platform admin action is required for each additional league.

For anything else — case-by-case questions about transferability, account changes, what happens if a founding-flagged league is deleted, etc. — these details are intentionally unspecified. Contact founders@racey.gg for case-specific questions.

Cap reference

Related guides

• Racey School index — the full list of role and program guides.
• League Admin Guide — how leagues are configured and where founding-league perks land.
• Glossary — definitions for plan tiers, leagues, and program-related terms.