One platform for clubs to run and grow
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.
- Role
- Founder & Product Designer
- Year
- 2025
- Platform
- Web, Owner Hub & runner app
- Scope
- 2 appsowner + runner
- Deliverable
- Stripepayments architecture
Evidence note: Screens use illustrative club, event, member and analytics content; visible names and figures are not live customer or commercial evidence.
On this page
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.
Decisions and delivery
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.
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.
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.
What shipped
As founder and Product Designer, I defined a two-app product model connecting club discovery, events, memberships, pace information and Stripe payments; launch, adoption and commercial outcomes are not claimed without evidence.
Pace worked better as product logic than organiser judgement
I derived event difficulty from recognised race paces so suitability became explicit product logic rather than organiser judgement.
Continue the conversation
Working through a similarly complex product decision?
I can help frame the problem, make the trade-offs visible, and carry the decision through to a usable delivery.
Get in touch