Happiest Team: All-in-One Community, Bookings, and Commerce for Real-World Clubs
A multi-tenant platform where each club gets its own space: members, content, optional paid membership, modular features (posts, polls, events, bookings, jobs, services, products, courses), admin tools, messaging, notifications, AI-powered discovery (HGPT), and sport leaderboards with real match flows.
We replaced the typical stack of chat groups, spreadsheets, booking links, and separate storefronts with one authenticated product tuned for clubs that actually operate offline and online.
Role: Full-stack platform engineering · Year: 2026 · Stack: Next.js, Supabase, Razorpay, TanStack Query, Radix, Tailwind
Multi-tenant
Clubs as isolated spaces with modules & permissions
Modular
Enable only what each club needs
Edge-first
Supabase functions as BFF for payments, HGPT, ops
CI quality
Jest across a11y, SEO, perf, regression
Context & problem
Clubs were drowning in fragmented tools
Clubs and communities (sports, hobbies, training businesses) often run on a patchwork: announcements in one channel, RSVPs in another, payments in a third, and inventory or class packs somewhere else.
That fragmentation increases drop-off, disputes, and admin time. Members lose trust when nothing feels like “one place,” and operators burn hours syncing spreadsheets to reality.
The product opportunity was a single authenticated journey: discover, join, participate, pay, and return, without re-explaining context in every tool.
Split attention channels
Critical updates compete with noise; nobody knows which surface is authoritative.
Payments disconnected from membership
Paid tiers, bookings, and storefronts each need verification and support. That gets painful when they are separate products.
Admin buried in one-off links
Booking links, forms, and shop URLs multiply; reporting and refunds become manual detective work.
Discovery does not respect privacy
Search and AI features risk leaking private club content if visibility is not modeled at the data layer.
Games as vanity lists
Leaderboards that never record real matches fail players who expect fairness and progression.
Operational nudges in inboxes only
Campaigns and reminders live in mail tools outside the product, so attribution and templates drift.
Goals we optimized for
Design constraints that shaped every module
- Single member journey: discover → join (free, paid, or invite) → participate → pay → return.
- One permission model: owners and admins control what members can do per module.
- Composable features: enable only what a club needs so the UI stays honest.
- Monetization without bolt-ons: memberships, bookings, packages, coupons, and product checkout in one auth context.
- Differentiation: hybrid search + AI answers (HGPT), per-club AI agent configuration, and game leaderboards with real match recording, not a static “top members” list.
Product thesis
One surface for people, money, and schedule
Happiest Team treats each club as the unit of value: its branding, modules, permissions, and commerce all live under one slug and one auth graph.
Heavy admin work (bookings back office, coupons, slots) stays behind clear information architecture while members see short, trustworthy paths.
Feature honesty: disabled modules do not clutter navigation; the club’s enabled set drives the entire experience.
Users & outcomes
Who uses the platform and what they get
Outcomes below use placeholders you can replace with live metrics as they stabilize (clubs onboarded, MAU, bookings or GMV, edge functions, CI runs).
| Audience | What they get |
|---|---|
| Visitors | Public directory, club pages, global feeds, HGPT discovery, and sign-up paths into the ecosystem. |
| Members | Join flows, optional intake, bookings, cart and checkout, courses, jobs and services browsing, messages, notifications, and leaderboards. |
| Owners / admins | Create-club wizard, edit club, permissions, intake forms, members, monetization, bookings admin (venues, activities, slots, packages, coupons), products, notification templates, AI agent settings, activity logs. |
| Operators | Product types including physical goods with Shiprocket, orders, tracking, and reviews when enabled. |
Outcomes to track: Clubs onboarded · Monthly active members · Bookings or GMV · Edge functions in production · Test suites run in CI.
Product walkthrough
What we shipped, organized by club reality, not slide headings
Each capability connects to the same member identity and permission graph, so commerce, bookings, and community never fight each other.
Clubs as the unit of value
Each club has a slug, branding (logo and thumbnail), categories, description, public or private mode, and toggleable modules: posts (baseline), polls, events, bookings, jobs, services, products, and courses. Granular permissions let admins decide what members can create or access.
Discovery
Home and directory browsing with SEO-oriented metadata; global feeds for cross-club post discovery. HGPT at /hgpt answers natural-language questions across clubs, posts, events, services, products, courses, jobs, polls, FAQs, and users, using hybrid keyword and semantic retrieval with streaming responses. Visibility respects membership for private content.
Joining & trust
Paths include direct join, invitation tokens, paid membership with payment verification, and optional intake forms for structured onboarding. Club reviews and activity logs support transparency and moderation.
Bookings
Members pick activities, slots, and packages, review, and pay when required. Admins configure venues (including Zoom-linked remote venues where meetings can be created automatically), activities, slots, packages, and coupons. QR and ticket generation supports check-in style operations.
Commerce
Club product catalogs, cart, checkout, orders, reservations with expiry logic, coupons, and optional Shiprocket shipping for physical goods when the seller has connected credentials.
Courses, jobs, and services
Structured courses with admin and management surfaces; jobs and services as first-class listing and detail experiences under the club.
Leaderboards & games
Template-based leaderboards with ranked players and match types (for example singles, doubles, and mixed for pickleball). New match wizards branch by sport; carrom templates route to dedicated scoring flows. Matches move through entry, scoring, and review so rankings reflect actual play.
Messaging & notifications
Direct messaging and in-club chat context. Club notifications support templates, conditional sends, broadcasts, and email delivery, so admins can run campaigns and operational nudges without leaving the product.
AI beyond chat search
Per-club AI agent configuration (personality and knowledge base) complements HGPT so clubs can expose an assistant grounded in their policies and content.
Key flows
How it works end to end
Short strips you can trace in the live product. Each flow shares the same auth and tenancy boundaries.
Visitor → member
Paid / invite club
Create club
Book
Shop
Record a match
Ask HGPT
These flows only work because permissions, payments, and visibility are enforced consistently, especially for private clubs appearing in search and HGPT results for the right members only.
Design & UX principles
How we kept a broad product legible
- Progressive disclosure: heavy admin stays behind clear IA; members see simple paths.
- Feature honesty: disabled modules stay out of navigation; the enabled set drives the shell.
- Mobile-first patterns: Radix primitives and Tailwind for density and accessibility baselines.
- Trust surfaces: legal pages, Zoom disclosure, cancellation and refunds, contact, all linked where a B2B buyer expects them.
Engineering highlights
Why this is a strong reference architecture for B2B2C community software
The stack favors explicit boundaries: the browser handles rich interaction, Supabase holds data and auth, and Edge Functions act as the secure BFF for anything that touches money, webhooks, or AI.
Next.js App Router
Server prefetch where it helps (for example directory surfaces) and client islands for search params and interactive flows.
Supabase backbone
Postgres, Auth, and a large Edge Function surface for payments, chat, HGPT, bookings, and operational jobs, which keeps secrets off the client.
Client state
TanStack Query for server state on complex club pages; predictable cache boundaries across tabs and roles.
High-stakes forms
Zod plus React Hook Form on flows such as create club and checkout-shaped experiences to reduce silent validation bugs.
Quality bar
Jest coverage across baseline, regression, performance, accessibility, and SEO-oriented tests; ESLint and TypeScript in the loop.
Third-party reality
Razorpay, Brevo, Shiprocket, Cloudinary, and Gemini integrated with explicit failure and validation paths, not optimistic assumptions.
Hybrid retrieval for HGPT combines keyword precision with semantic recall; embeddings and pgvector-oriented storage keep answers grounded in club-approved content.
Technology stack
Frontend
Next.js 15 · React 19 · TypeScript · Tailwind CSS · Radix UI · TanStack React Query · React Hook Form · Zod · Framer Motion · Recharts · Lucide · date-fns · Sonner · next-themes
Backend & data
Supabase (PostgreSQL, Auth, Edge Functions / Deno) · JWT where needed · Vercel (frontend) · Node 22+ / npm 10+ in repo constraints
AI · Payments · Ops
Google Gemini (generation + streaming) · embeddings pipeline · Razorpay · Brevo · Shiprocket · Cloudinary · sharp
Challenges & decisions
Where naive shortcuts would have broken trust
Multi-tenancy + visibility
Search and HGPT must never leak private club content; results combine public clubs with member-accessible private content using consistent visibility rules.
Monetization complexity
Memberships, booking payments, and e-commerce share patterns but have different lifecycles. We handled that with dedicated edge functions and verification steps rather than one opaque pay endpoint.
Leaderboard correctness
Sport-specific rules and UI branches (pickleball versus carrom) avoid forcing one generic scorer that would be wrong for either game.
Operational load
Notifications, webhooks, and reservation expiry need background-style triggers. We implemented those as dedicated functions and checks rather than only client timers.
Results & reflection
What worked and what we would deepen next
What worked
- Unified join plus pay flows inside one auth graph reduced support load for club admins.
- Edge Functions as a BFF kept payment and AI secrets off the client while staying close to Postgres.
- Modular club features made sales conversations faster: enable bookings or commerce without re-platforming.
What we would iterate next
- Deeper analytics dashboards for club operators (funnels beyond raw activity).
- More automated embedding refresh as content churn increases.
- Internationalization once non-English clubs become a meaningful segment.
Shipping B2B2C community software is less about “more features” and more about ruthless permission and payment correctness. When those foundations are boring and reliable, clubs actually adopt the creative modules (HGPT, leaderboards, commerce) because members trust the core.
Happiest Team is opinionated software for real clubs.
One product surface for people, money, and schedule, with AI and games as differentiators, not afterthoughts.
If you are scoping a multi-tenant community, booking, or commerce platform with similar constraints, the patterns here transfer: modular tenancy, edge-secured payments, and retrieval stack that respects membership.
Visit the live product, then talk to us if you want the same discipline on your roadmap.
Happiest Team · Community, bookings & commerce FAQ
HGPT visibility, modular clubs, payments, leaderboards, and shipping: common questions from teams evaluating a build like this.
How does HGPT avoid leaking private club content?
Hybrid retrieval applies the same visibility rules as the rest of the app: private posts and resources only appear for authenticated members with access. Public clubs and assets remain discoverable for visitors.
Why separate edge functions for memberships, bookings, and checkout?
Each flow has different verification, webhooks, and failure modes. Dedicated functions keep lifecycles explicit and easier to audit than a single generic pay endpoint.
Can a club run only part of the product?
Yes. Modules toggle per club, and navigation reflects only what is enabled so members are not buried in disabled features.
How are leaderboards different from static “top member” lists?
Matches move through entry, scoring, and review with sport-specific templates, so rankings reflect recorded play, not vanity metrics.
How does physical product shipping work?
When a seller connects Shiprocket credentials, rates, tracking, and webhooks integrate with orders; digital and service products follow the same cart context without shipping.
Planning a multi-tenant community, booking, or commerce platform?
Happiest Team shows how one auth graph, modular club features, and edge-secured integrations can replace a pile of disconnected tools without giving up privacy or payment correctness.
- ✓Tenancy, RLS, and HGPT visibility modeled together, not patched in later
- ✓Next.js App Router + Supabase Edge Functions as a disciplined BFF layer
- ✓Razorpay, Shiprocket, Brevo, and Gemini wired with explicit failure paths
- ✓Tests that cover accessibility, SEO, performance, not only happy paths
No pitch deck required. Bring your constraints and we will map what ships first.
Share Your Ideas Here!
We are all ears!