# Southbound & Crown — Product Requirements Document
### Public site, member portal, and admin console — full rebuild

| | |
|---|---|
| **Status** | Draft — ready for board review. Design direction and several business-policy items are marked **OUTSTANDING** below and need a decision before Phase 2 engineering starts. |
| **Owner** | Chris Howe (SolveItSam) for Southbound & Crown |
| **Last updated** | 2026-07-22 |
| **Related documents** | `00-ORIGINAL-ANALYSIS.md` (current-site audit) · `01`–`05` (early written concepts) · `06-MASTER-REDESIGN-BRIEF.md` (creative + functional brief this PRD formalizes) · `07-DIRECTION-WAYFINDING.md` / `sbc8.html` (finalist A) · `08-DIRECTION-SCARVES-UP.md` / `sbc9.html` (finalist B) |

This document assumes you've read `06-MASTER-REDESIGN-BRIEF.md` — it does not re-derive the brand research, the current-site content audit, or the anti-pattern list from the 8 rejected concepts; it references them by section instead. What's new here: the two finalist directions that came out of that brief, formal requirements with priority, and every open decision the client (Chris / the SBC board) still needs to make, called out explicitly rather than left implicit.

**Per instruction, this PRD makes a real decision everywhere it reasonably can.** Where a question is genuinely a business or creative call that isn't mine to make unilaterally, it's marked **OUTSTANDING** with a recommendation attached — not left blank.

---

## 1. Executive summary

Southbound & Crown is replacing its Squarespace site with a purpose-built platform covering three surfaces: a public marketing site, an authenticated member portal, and an admin console for the volunteer board. Eight early design concepts were rejected as generic/AI-looking (brief §2); two new finalist directions — **Wayfinding** (night, interstate-signage system) and **Scarves Up** (daylight, knitwear system) — were built against a forbidden-pattern list derived from that rejection and are both genuinely strong, deliberately opposite candidates (§6 below). The functional scope goes well beyond a homepage: full commerce (replacing Squarespace's store), Stripe-backed membership subscriptions, a member self-service portal, and an admin system for the specific, real, recurring workflows the board already does by hand (the Atlanta bus roster, rec-team rosters, reports, newsletters).

**What this PRD adds beyond the brief:** priority-tagged requirements, the two finalist designs and a recommendation between them, success metrics, a phased delivery plan, and a consolidated list of every open business decision.

---

## 2. Background

- Current site: Squarespace, southboundcrown.com (confirmed canonical domain — see brief §1).
- Current commerce: Squarespace Commerce selling memberships (individual/family/Triumph tiers), apparel, flags, scarves, patches (brief §5.3).
- Current membership management: Squarespace member accounts — no dedicated admin tooling for reports, sign-up sheets, or newsletters; these are presumed to be handled today via spreadsheets, email, and Discord (see §14, OUTSTANDING — actual current admin workflow unconfirmed).
- Design process to date: 8 concepts rejected (brief §2) → master brief written to prevent a 9th generic attempt → two finalist directions built and self-critiqued against the brief's forbidden-pattern list (§6 below).

---

## 3. Goals

| Goal | How it's measured |
|---|---|
| Replace Squarespace with a platform SBC fully owns and controls | Squarespace subscription cancelable post-launch; zero remaining dependency |
| A design that reads as bespoke, not AI-templated | Zero forbidden patterns from brief §2 present at launch (manual audit against the checklist) |
| Members can self-serve account/payment/subscription changes without emailing the board | Member portal ships with 0 of those 4 actions requiring board intervention |
| Cut board admin time on recurring logistics (bus roster, rec rosters, reports) | Qualitative target: each of those workflows completable in single digits of minutes, not a spreadsheet-and-email cycle (§13) |
| Meet the "$50k, award-caliber" bar set in the original brief | Ships one of the two finalist directions (or an explicitly-approved blend) fully realized, not diluted by scope-cutting |

## Non-goals (carried forward from brief §11 — unchanged)

No native mobile app · no in-house chat/forum (Discord stays the real-time layer) · no match-ticket sales/checkout · no granular admin permission tiers at launch · **no in-app voting/election system in v1** (new decision, see §7.4 — SBC's board elections are a membership benefit to describe, not a feature to build yet).

---

## 4. Users & personas

| Persona | Who | Needs |
|---|---|---|
| **Prospective member** | Someone who found SBC via social/word of mouth, hasn't joined yet | Understand what SBC is, see both clubs represented, join with minimal friction |
| **Active member** | Paying member, may or may not be tech-savvy, spans a wide age range including families | Manage their own account (§7.2), find tailgate/game info, buy merch, feel represented whichever club they follow |
| **Volunteer board admin** | Runs SBC alongside a full-time job/life, not a technologist | Do recurring, time-pressured tasks (rosters, reports, newsletters) fast, without needing to remember how the tool works between uses |
| **Guest/media** | Journalists, sponsors, rival supporters groups, league/club contacts | Get the "who we are" story and credibility signals (SEC Quarterly quote, founding story) quickly |

---

## 5. Scope & requirements

Requirements below carry a priority: **P0** (launch blocker), **P1** (launch-desired, can trail by a few weeks if needed), **P2** (fast-follow, explicitly not a launch blocker). This reformats brief §6–§8 with priority added — see the brief for full field-level detail on each item.

### 5.1 Public site (brief §6)

| Requirement | Priority |
|---|---|
| Home — resolves the two-club identity (brief §3.1) | P0 |
| About — origin story, co-founders, both-club explanation | P0 |
| Tailgate — game-day info, modeled as admin-editable Event data, not hardcoded copy | P0 |
| Merchandise storefront — browse, variants, cart, checkout (Stripe) | P0 |
| Membership / Join — benefits, tiers, purchase flow | P0 |
| Login — entry to member portal | P0 |
| Gallery — real photo upload/display pipeline | P1 (blocked on real photography — see §14) |
| Chants, Media page | P1 — content parity, not a design priority per brief §6 |

### 5.2 Member portal (brief §7)

| Requirement | Priority |
|---|---|
| Update username, email | P0 |
| Update mailing address | P0 |
| View/update saved payment methods | P0 |
| View/manage subscription (tier, renewal, cancel/change) | P0 |
| Full order history with receipts/invoices | P0 |
| Optional date-of-birth field (admin-only use, never public) | P1 |
| Member-only content links (Discord invite, ticket-access info, travel coordination) | P1 |

### 5.3 Admin console (brief §8)

| Requirement | Priority |
|---|---|
| Member list with status, search/lookup | P0 |
| Reports: active members, mailing/address list | P0 |
| Report: upcoming birthdays | P1 |
| Products: create/edit/list, variants, sale pricing, inventory, categories | P0 |
| Orders: list, sales reporting by item/category, refunds | P0 |
| Events & sign-up sheets: generic create/edit, custom fields, capacity + waitlist, response table | P0 |
| Sign-up sheets proven against the two named real use cases: Atlanta bus roster, rec-team rosters (Queen City Cup + adult league) | P0 |
| Sheet communication: email a sheet, remind non-responders, send history | P1 |
| Newsletters: compose, draft, schedule, segment (club/tag/sheet-roster), send log | P1 |
| CSV export on every list/report | P1 |
| Bulk actions (bulk email a filtered list, bulk export) | P2 |
| Duplicate a prior sign-up sheet or newsletter | P2 |
| Saved/reusable report filters | P2 |

---

## 6. Design direction — status and recommendation

Two finalist directions exist, both built against the brief §2 forbidden-pattern list and both self-critiqued item-by-item in their own docs. Neither has been formally approved. **This is the single biggest OUTSTANDING decision in this PRD** (§14.1) — everything in Phase 2 onward depends on it.

### 6.1 Direction A — "Wayfinding" (`sbc8.html`, `07-DIRECTION-WAYFINDING.md`)

Night/interstate-signage system. The metaphor: SBC is a club founded 25 miles from the stadium that rents a bus every year (and needs a real roster of who's on it), and drives members across two states to two clubs — so the site borrows the most legible visual language ever designed for exactly that (guide-sign panels, exit tabs, mile markers). Two-club problem solved as one overhead gantry, two destination tabs. Ground `#0A0F1A`, sign navy `#132340`, Charlotte blue `#1A85C8`, Triumph gold `#F4C25E` as a restrained accent. Type: Overpass (the open-source descendant of the actual highway-sign typeface) + Barlow + Newsreader Italic for the hospitality voice. Signature element: a schematic map of the Royal Family Tailgate Lot as the hero centerpiece.

**Strengths:** the single most differentiated concept-to-club fit produced so far — nothing generic could arrive here by accident. Signage is built for legibility at a glance by everyone, which structurally (not cosmetically) answers the brief's "not just tech-savvy 20-somethings" requirement.

**Risk:** dark-mode-primary marketing sites can read as moodier/more premium-urban than "warm Southern hospitality," and that tension needs to survive contact with real content and real members before it's called final.

### 6.2 Direction B — "Scarves Up" (`sbc9.html`, `08-DIRECTION-SCARVES-UP.md`)

Daylight/knitwear system, built after Chris asked for something "completely different, lighter, all the bells and whistles." The metaphor: the scarf is the single most supporters-culture-true object SBC has — it's the lead item in the member kit, sold in three seasons in the catalog, and "scarves up" is the actual pre-kickoff terrace gesture. The hero is a woven SVG scarf that raises itself; a yarn thread stitches the whole page together; the two-club problem is solved as one scarf with two different-colored ends. Paper `#F6F9FC`, ink `#0F1D2E`, Charlotte blue, Triumph gold and slate as accents. Type: Clash Display + Satoshi — **the exact pairing already shipped and validated in Tailgate HQ** (brief §4.6) — plus Gambetta italic for the hospitality/quote voice.

**Strengths:** warmer, more immediately welcoming to a family-friendly, broad-age audience; reuses a font pairing this client has already seen, shipped, and liked, which is a real continuity/brand-equity signal, not a cold start; the scarf is a more universally legible symbol on first glance than the highway metaphor (no translation required to "get it").

**Risk:** "all the bells and whistles" motion (self-drawing yarn, wool-wobble displacement, ambient sways) is more implementation-heavy to build correctly and keep performant than Wayfinding's more restrained motion plan — needs real engineering-effort estimation before commit, not just design sign-off.

### 6.3 Recommendation

**Lead with Scarves Up (Direction B) for the public marketing site, and recommend evaluating a dark theme drawn from Wayfinding's token system for the member portal and admin console specifically.** Reasoning:

1. SBC's own stated values are Southern hospitality and family-friendliness first; Scarves Up's daylight warmth serves that more directly on first impression, where Wayfinding's nighttime sophistication is a slower-reveal payoff.
2. Scarves Up reuses a font pairing (Clash Display/Satoshi) this exact client has already shipped and approved — measurably lower brand-consistency risk than introducing Overpass/Newsreader as an entirely new voice.
3. Dark UI is a better-fit pattern for data-dense admin screens regardless of which direction wins the public site (brief §3.2's "prove it on a utility screen" requirement is easier to satisfy well in a dark, high-contrast admin theme) — so Wayfinding's system doesn't have to be discarded even if it doesn't lead publicly; it can own the admin/member-portal surface where a signage-grade information hierarchy is a genuine functional advantage, not just an aesthetic choice.

This is a recommendation, not a decision — see §14.1. If the board prefers Wayfinding as the single unified system across all three surfaces (public, member, admin), that is a fully legitimate call the finalist doc already supports; the brief's own requirement (§3.2) that the direction be proven on a dense utility screen applies either way and has not yet been done for either finalist.

---

## 7. Notable decisions made in this PRD (not left open)

Items the brief left implicit or didn't address, decided here so Phase 2 engineering isn't blocked on them:

### 7.1 Membership billing model
**Decision: auto-renewing annual subscription via Stripe Billing, with self-serve cancel-anytime in the member portal.** The current Squarespace catalog's "2026 Membership" naming suggests manual annual repurchase today, but the original request explicitly asked for member-managed "subscriptions," and auto-renew is both the better retention mechanism and the only way "manage subscription" (brief §7.2) means anything real. **Confirm this with the board before build** — it's a genuine change in member experience (a member who does nothing gets rebilled) and needs a clear renewal-notice email and an easy cancel path to be fair to members. Flagged as a confirm-not-decide item in §14.

### 7.2 Product data model
**Decision: one unified catalog table serving both merch and membership-as-a-product** (brief §6, §9) — a Stripe Price object per tier/variant, sale-price support matching the existing struck-through-original-price pattern (brief §5.3).

### 7.3 Roles
**Decision: two roles at launch — `member`, `admin`** (brief §9) — no merch-admin/board-admin split yet, addable later without a schema rewrite.

### 7.4 Governance / voting
**Decision: not building in-app voting for v1.** SBC's member-elected governance (brief §1) is real and matters to the brand voice, but building a secure election/voting system is a meaningfully different (and higher-stakes, integrity-sensitive) product than everything else in this scope. **Recommendation:** describe voting rights as a benefit on the Membership page; continue running actual elections through whatever mechanism the board already trusts (paper ballot, a form, a third-party voting tool) until there's a dedicated phase for it. If the board disagrees and wants this in v1, treat it as a scope addition requiring its own security review — not a footnote feature.

### 7.5 Analytics
**Decision: a privacy-respecting, cookie-consent-free analytics tool** (e.g. Vercel Analytics or Plausible) over Google Analytics — consistent with a member-data-conscious platform, avoids a cookie-consent banner most of this audience would never expect on a supporters-club site, and is a lower-lift decision than the payment/legal items below.

---

## 8. Technical architecture

Carried forward from brief §9 as committed direction, not open:

- **Framework:** Next.js (React), one application with role-gated `/admin` and member-portal routes.
- **Auth + DB:** Supabase (Postgres, Auth, Storage, Row-Level Security).
- **Payments/subscriptions:** Stripe Billing + Payment Element, custom branded UI (not the generic hosted Customer Portal).
- **Email:** Resend (transactional + segmented broadcast).
- **Media:** Supabase Storage, responsive/lazy delivery.
- **Hosting:** Vercel.
- **Analytics:** Vercel Analytics or Plausible (§7.5).

---

## 9. Content & data migration

- **Content parity source:** current live site content scraped into brief §5 (sitemap, membership benefits, product/pricing catalog) — usable as seed data directly.
- **Member data migration from Squarespace:** **OUTSTANDING** — whether Squarespace's member/commerce data is exportable in a usable format (CSV of members, order history, saved payment tokens) has not been confirmed. Saved payment methods in particular typically cannot be migrated between processors at all — members will very likely need to re-enter a card on first login post-launch. Plan for an explicit "update your payment method" email campaign at launch, not a silent migration assumption.
- **Real photography for Gallery:** **OUTSTANDING.** Both finalist directions explicitly avoided placeholder/stock imagery rather than fake it (brief's design-mandate spirit) — real tailgate/event photos need to be sourced from the board/members before Gallery can ship for real, not mocked with stock images.
- **Chants page content:** carry over from current site; if any chants are adaptations of copyrighted songs, flag for a quick legal gut-check before publishing verbatim lyrics on the new site (unconfirmed whether this is already a concern on the current site).

---

## 10. Security & privacy

- PCI scope minimized by using Stripe Elements/Payment Element (no raw card data touches SBC's servers) — brief §9.
- RLS-enforced separation between member-owned data and admin-visible data (brief §9); DOB field never exposed outside the admin birthday report (brief §7.1/§8.1).
- Destructive admin actions require confirmation (brief §10).
- **OUTSTANDING:** SBC's legal entity status (nonprofit, LLC, unincorporated association) is unconfirmed and affects the Stripe merchant account setup, whether membership dues can be framed as tax-deductible, and what terms/privacy-policy language is accurate. **Recommendation:** confirm entity status before Stripe account creation, and have actual legal review (not AI-drafted boilerplate) on Terms of Service and a Privacy Policy before collecting payment data — neither exists today per the current-site audit and both are required before launch.
- **OUTSTANDING:** minors' data — family memberships imply some member-linked individuals are children. No feature in this scope collects data directly from a child (parents manage the account), but flag for the legal review above rather than assume it's a non-issue.

---

## 11. Success metrics

| Metric | Target | Status |
|---|---|---|
| Core Web Vitals (field data, p75) | LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1 | Committed — standard, not negotiable |
| Accessibility | 0 critical/serious automated-audit violations; WCAG 2.1 AA | Committed |
| Uptime | 99.9% monthly | Committed (standard for this scale of commerce site) |
| Zero forbidden design patterns (brief §2) present at launch | Pass/fail manual audit | Committed |
| Admin: time to build & send an Atlanta bus roster or rec-team roster | Single digits of minutes end-to-end | Committed as a qualitative bar; no numeric baseline exists to compare against — **TBD** whether the board can supply a "how long does this take today" estimate to make the improvement measurable |
| Membership purchase funnel completion rate | Track from launch; no baseline exists to set a numeric target against | **TBD** — instrument from day one, set a target after the first full membership cycle |
| Newsletter open rate | Typical community/nonprofit sends run roughly 30–40% — usable as a rough reference, not a commitment | **TBD** — depends on list quality/segmentation, which doesn't exist yet |

---

## 12. Phased delivery plan

Carries forward brief §12.6, expanded with rough sequencing (no calendar dates — see §14.4):

| Phase | Scope | Gate to proceed |
|---|---|---|
| **0 — Direction lock** | Board reviews `sbc8.html` / `sbc9.html`, decides §6.1 vs §6.2 (or an approved blend); resolves §14's business-policy items | Written sign-off on direction + billing model before any Phase 1 build work |
| **1 — Token system + 2 screens** | Chosen direction's design tokens finalized; homepage built; one dense utility screen (admin member table or member payment-methods form, per brief §3.2) built to prove the direction survives real density | Board sign-off on both screens |
| **2 — Public site** | Full brief §6 scope | Content-parity review against current live site |
| **3 — Member portal** | Full brief §7 / PRD §5.2 scope, Stripe integration live | End-to-end test: join → manage payment method → cancel, by a real (non-technical) tester |
| **4 — Admin console** | Full brief §8 / PRD §5.3 scope | A board member — not an engineer — successfully builds and sends the Atlanta bus sign-up sheet unaided |
| **5 — Migration & cutover** | Data migration (§9), DNS cutover, Squarespace cancellation | Rollback plan documented before DNS change |

---

## 13. Risks & mitigations

| Risk | Mitigation |
|---|---|
| Direction decision (§14.1) stalls the whole project | Phase 0 gate makes this the explicit first step, not something resolved mid-build |
| Auto-renew billing surprises members used to manual annual purchase (§7.1) | Confirm with board pre-launch; clear renewal-notice email; obvious self-serve cancel |
| Payment-method migration gap leaves members unable to check out post-launch (§9) | Proactive "update your payment method" campaign timed to launch, not a silent assumption |
| Scarves Up's heavier motion budget slips the timeline if underestimated (§6.2) | Get an engineering-effort estimate on the motion system specifically before Phase 0 sign-off, not after |
| No real photography exists for Gallery (§9) | Treat as a content dependency owned by the board, tracked separately from engineering scope, not a blocker for Phases 1–4 |
| Legal/entity-status gap delays Stripe account setup (§10) | Surface to board immediately — this can be resolved in parallel with Phase 0/1 design work if started now |

---

## 14. Open questions — consolidated (TBD / OUTSTANDING)

Everything flagged above, in one place:

1. **OUTSTANDING — Design direction.** Wayfinding vs. Scarves Up vs. a blend (§6). Recommendation given (§6.3); needs board sign-off.
2. **TBD — Confirm auto-renewing subscription model** with the board (§7.1) before Stripe Billing implementation; a real change from the current apparent manual-annual pattern.
3. **TBD — SBC's legal entity status** (§10) — affects Stripe setup and ToS/Privacy Policy accuracy. Needs real legal review, not AI-drafted terms, before payment collection goes live.
4. **TBD — Squarespace data export feasibility** (§9) — confirm what member/order data can actually be exported; assume payment methods cannot migrate and plan the re-entry campaign regardless.
5. **TBD/OUTSTANDING — Real tailgate/event photography** (§9) — a content dependency, not an engineering one; needs board/member sourcing before Gallery ships for real.
6. **TBD — Refund and membership-cancellation policy specifics** — not defined anywhere in current-site research; needed before Stripe Billing cancellation flow copy can be finalized.
7. **TBD — Merch fulfillment/shipping process** — who packs and ships physical orders today, and does that stay a volunteer process or change with the new system. Unconfirmed; out of this PRD's research scope.
8. **TBD — Payment-processing fee handling** — absorbed by SBC or passed to the buyer at checkout (a Stripe-config-level decision, cheap to implement either way once chosen).
9. **TBD — Chants page copyright check** (§9) — quick legal gut-check if any chant text is an adaptation of copyrighted song lyrics.
10. **TBD — Current admin baseline** — no confirmed data on how long the board currently spends on the bus roster / rec rosters / reports today, which limits how precisely §11's admin-time metric can be validated as "improved." Board estimate would resolve this cheaply.
11. **TBD — Calendar timeline.** This PRD sequences work by phase and gate (§12), not by date, because season calendar, board-approval cadence, and available engineering time are all unknown from the current-site research alone.
12. **TBD — Actual engagement budget/scope**, as distinct from the "$50k-caliber quality bar" language in the original creative brief, which was a quality target, not a confirmed contract value.

---

## 15. Appendix — related documents

- `00-ORIGINAL-ANALYSIS.md` — current Squarespace site audit
- `01`–`05` — five early written concept explorations (superseded)
- `demo.html`, `sbc2.html`–`sbc7.html` — eight rejected built concepts (brief §2)
- `06-MASTER-REDESIGN-BRIEF.md` — the creative + functional brief this PRD formalizes
- `07-DIRECTION-WAYFINDING.md` / `sbc8.html` — finalist direction A
- `08-DIRECTION-SCARVES-UP.md` / `sbc9.html` — finalist direction B