How can club leaders grow a running community without stitching together chat, spreadsheets, and bank transfers?
An all-in-one platform for running community leaders. Publish your club, run events, manage memberships, and take payments, while runners find sessions matched to their pace.
Project frame: Runite: one platform for running clubs to grow, run events, and get paid
Scope note: The screens demonstrate the product model using illustrative club, event, member, and analytics content. Visible names and figures are not presented as live customer or commercial evidence.
Role
Founder & Product Designer
Year
2025
Platform
Web · Owner Hub & runner app
2 apps
focused audiences
A leader hub and runner experience share the same product model without crowding each other.
Stripe
payments model
Ticketing, memberships, and platform fees are designed into the shared product architecture.
Reconstructed artifact · Runite club platform
01 · Context
The problem
The product premise is that club leaders should not need a group chat, a member spreadsheet, and bank transfers to run one community. Runite brings publishing, events, memberships, pace information, and payments into a single model.
02 · Evidence
What shaped the direction
Community-leader journey
Mapped how leaders announce runs, track members, collect money, and answer repeated questions before and after events.
Runner confidence
Runners needed difficulty, pace, route, timing, and social context before committing to a session.
Pace-model design
Difficulty labels were grounded in real running paces instead of vague organiser guesses.
Business-model constraint
Subscriptions and event fees had to support club growth without creating payment admin for volunteers.
03 · Process
How it came together
The brief
Running clubs are high-trust, high-frequency communities, and badly served by
the fragmented tool model the concept is designed to replace: group chat for
announcements, a spreadsheet for members, and bank transfers for fees. Runite's
bet is that publishing a club, running events, and getting paid are one product
problem rather than three.
Reconstructed artifact · Runite club platform
The Owner Hub: a club leader's communities and events in one place.
Two apps, two audiences
Leaders and runners want very different things, so Runite is designed as two
focused apps over a shared API: an Owner Hub where leaders create communities,
schedule events, and manage billing, and a runner app where people discover
clubs, book events, and pay. Splitting them keeps each surface focused, so
neither audience wades through the other's controls.
Matching runners to the right run
The sharpest design problem was ability. Show every event to everyone and
beginners get scared off while fast runners get bored. So every event carries a
difficulty (beginner, progressing, intermediate, advanced) and Runite
infers it from real paces (5k through marathon) rather than asking an organiser
to guess. A colour-coded badge lets a runner self-select a session that fits in
a single glance.
Reconstructed artifact · Runite club platform
A runner's event view: difficulty badge, location, and one-tap booking.
How money moves through the platform
Money was a first-class concern. The product model uses Stripe Connect so
leaders can be paid directly for tickets and memberships while the platform
takes a configurable fee, with Club and Club Pro subscription tiers for
owners on top. The implementation architecture uses a lean Vite/React/Chakra
monorepo on Firebase and Render: runner app, owner portal, and API in one codebase.
What I built
Runite brings the disconnected club-management model into one coherent product
direction, with discovery, events, memberships, pace information, and payments
in a single loop. Launch status, adoption, and commercial outcomes remain
separate evidence questions rather than claims made by this case study.
04 · Craft
Decision trail
01Split the product into two focused apps over a shared API: an Owner Hub for club leaders and a runner-facing app, so each audience only carries the surface it needs.
02Inferred event difficulty from real running paces (5k through marathon) and surfaced it as a colour-coded badge, so runners self-select sessions that fit instead of guessing.
03Designed payments around Stripe Connect so tickets, memberships, platform fees, and owner tiers share one explicit money model.
04Kept the implementation architecture lean with a Vite/React/Chakra monorepo on Firebase and Render, covering the runner app, owner portal, and API in one codebase.
