Runite.Club
One product model for the people who find running communities and the organisers who publish, operate and fund them.
- Role
- Product model, UX, interface design and delivery
- Audiences
- Runners and community owners
- Surfaces
- Runner experience, Owner Hub and shared services
- Evidence
- Live runner product, public owner preview and labelled demonstrations
Running communities are social systems, not event directories
Running groups often assemble their service from chat threads, social posts, sign-up forms, map links, spreadsheets and bank transfers. That fragmentation is inconvenient for an organiser, but it is also a trust problem for a runner. A person deciding whether to attend needs to understand the group, expected pace, difficulty, location, time, cost and social context before committing.
Runite reframed that collection of tasks as one community lifecycle. The runner-facing product supports discovery, community detail, events, maps, follows, reviews, sign-in, memberships and tickets. The Owner Hub gives the organiser a separate operating surface for publishing, members, sessions and connected commerce. Both experiences resolve to the same community, event, person and payment concepts, so an update made by an owner can become useful context for a runner without manual re-entry.
QDev shaped the information model and both experience layers, then translated them into a React product backed by Firebase, maps and Stripe Connect. The role covered product structure, interaction design, interface delivery and the seams between public discovery and owner operations. There are no adoption, revenue or event-volume claims in this case because those figures were not part of the evidence reviewed for publication.
A sequence built around confidence, participation and operation
2025
Model the community before the marketplace
Defined communities, events, people, pace, place and ownership as connected concepts rather than a flat catalogue of runs.
2025
Build the runner experience
Created public discovery, community detail, event views, maps, identity, follows and reviews around the questions runners ask before joining.
2025 to 2026
Add the Owner Hub and commerce
Separated organiser controls into a focused workspace while connecting memberships and ticketing through Stripe Connect.
14 July 2026
Record the public evidence state
Captured the live runner and owner entry points. Richer event and discovery screens remain clearly labelled demonstrations where live records were unsuitable for publication.
Every surface in the product system
Capability status definitions
- LiveAvailable in a public or deployed product.
- ImplementedBuilt, but release or approval is not evidenced.
- DemonstrationA labelled example using simulated data.
- ExploratoryResearch, specification or prototype only.
Runner discovery
The public route into communities and events, organised around fit and confidence.
- Community and event discovery
- Pace, difficulty, date and location context
- Maps and public detail pages
- Account entry, follows and reviews
RepositoryCanonical private Runite repository, exact origin unverified
Owner Hub
A separate operator experience is implemented, with a public preview rather than an authenticated workflow used as publication evidence.
- Community and event publishing
- Member and session management
- Membership and ticket operations
- Operating signals kept out of runner navigation
RepositoryShared Runite product boundary
Shared product model
Firebase-backed identity and product data implement continuity between public state and owner actions.
- Shared community and event records
- Identity and access state
- Runner-to-owner data continuity
- Deployment through Render
RepositoryFirebase and application service layer
Connected commerce
Stripe Connect supports payments where the organiser remains the commercial actor.
- Membership payment paths
- Event ticketing paths
- Connected-account boundary
- Product state around a payment outcome
RepositoryStripe Connect integration
Populated discovery study
A simulated catalogue tests hierarchy, density and the handoff into owner tools.
- Community card hierarchy
- Discovery scanning
- Runner and owner route separation
- Sample content only
Event detail study
A simulated event tests the decision sequence before joining or buying.
- Pace and difficulty
- Map and location context
- Calendar action
- Sample event only
One community, two focused experiences
From publication to participation
- PublishCreate the community, its identity and upcoming sessions.
- DiscoverFind a suitable club or event through public pages and maps.
- JoinResolve identity, group rules, a ticket or a membership.
- OperateManage events, people and connected payment state in the Owner Hub.
The loop describes implemented product responsibilities. It does not imply a published number of completed events, members or payments.
Inspect live product (opens in a new tab)Live and demonstration evidence
The public Owner Hub preview and labelled studies make the audience split, information hierarchy and event decision path inspectable without presenting sample content as customer activity.
Illustrative preview
Demonstration data
Demonstration dataThe choices that hold the two-sided product together
Separate experiences, shared concepts
- Decision
- Give runners and owners different applications while keeping community, event, identity and commerce concepts aligned.
- Why
- Each audience has a different next action. Mixing publishing controls into discovery would increase noise and risk.
- Consequence
- Public changes and owner tooling can evolve independently without duplicating the underlying product model.
- Tradeoff
- The boundary needs deliberate contracts and end-to-end testing whenever shared records change.
Make pace a discovery property
- Decision
- Treat pace and difficulty as first-class information near the event decision, not buried descriptive copy.
- Why
- A runner needs to judge physical and social fit before location or visual promotion can be persuasive.
- Consequence
- Event pages answer the suitability question earlier and establish a reusable vocabulary for search and filtering.
- Tradeoff
- Organisers must describe sessions consistently enough for the labels to remain useful.
Anchor discovery in communities
- Decision
- Let an event inherit trust from its community rather than presenting every session as an isolated listing.
- Why
- Running participation depends on who hosts the session, what the group is like and whether the experience repeats.
- Consequence
- Reviews, follows, event history and membership can accumulate around a durable identity.
- Tradeoff
- The model is richer than a simple event board and asks more from initial community setup.
Use Stripe Connect for organiser commerce
- Decision
- Connect memberships and tickets to organiser payment accounts through Stripe Connect.
- Why
- The platform needs a clear boundary between product experience and the organiser receiving funds.
- Consequence
- Commerce can sit inside the same participation journey without Runite becoming a manual payment ledger.
- Tradeoff
- Onboarding, account state, refunds and payment exceptions become explicit operational workflows.
What runs where, and what remains unverified
Private application repository
Runite product application
ImplementedBuilds the public runner experience and the owner-facing product around one community and event model.
- React
- Firebase
- Maps
- Render
Public runner and Owner Hub deployments were inspected. Exact repository origin and production commit remain pending verification.
Managed data and identity
Firebase service boundary
LiveHolds shared identity and product state used across discovery, community detail, events and owner workflows.
- Firebase
- Authentication
Stack evidence supports the boundary, but this case does not claim an independent security assessment.
External commerce service
Stripe Connect boundary
ImplementedConnects membership and ticket payment paths to organiser accounts and returns payment state to the product.
- Stripe Connect
Capability evidence supports the integration. No payment-volume or revenue metric is published here.
A community product that respects both sides of participation
Runite now gives runners a coherent route from discovery to trust and participation, while organisers get a separate route from publishing to operation. The value is not simply the number of features. It is that pace, place, people, events, memberships, tickets and payment state belong to one product model and can be presented differently to each audience.
The next evidence milestone is operational rather than cosmetic: reconcile the live deployment to its canonical repository and commit, then publish measured activation, repeat participation and organiser outcomes when those figures are approved. Until then, the case stops at what can be inspected and supported.
Building for a community and its operators?
Connect people, operations and payments through one product build.
Discuss a project