YouTooCanRunMass-participation Sports & Fitness EventsWeb Development
App & AI Development2026
One Flutter codebase running 21 events across 5 brands
A single Flutter app and Laravel backend that carries every YouTooCanRun edition — 21 events, 5 brands, 14,989 participants — configured rather than forked, with per-event scoring engines, health data from six sources, and an organiser admin panel that keeps each edition isolated.
- 21 events
- 5 brands, one codebase
- 14,989
- Participants carried
- 853
- Automated tests
The challenge
YouTooCanRun does not run one event. It runs many, for different brands, often at the same time, and each one is judged differently — one on consistency across a hundred days, another on a cumulative step goal, another on distance. Each also needs its own app identity, its own leaderboard structure and its own organiser controls. Building an app per event would have meant a separate codebase, a separate release cycle and a separate set of defects for every edition.
The harder constraint is that the events are live with real participants while the next ones are being built. A change made for one edition must not alter the behaviour of another that is mid-challenge, and a participant whose steps stop counting is not something that can wait for a sprint boundary.
What we were asked to do
Build and run one platform that can carry many events at once: a single app that takes its identity and its rules from the event it is pointed at, a backend where an organiser can change those rules without a developer, and a release process that can ship to both app stores without disturbing the editions already running.
What we did
Built one app that serves every event
A single Flutter codebase carries all the editions. Branding, event rules, the tabs a participant sees and the features that are switched on all come from the event's own configuration, so a new edition is set up rather than written.
Kept each event's rules behind its own flag
Every scoring behaviour sits behind a per-event switch that defaults to off. Code for one event is inert for the rest until an organiser turns it on, and the failure mode of a mistake is "the feature is absent", never "it appeared on somebody else's event".
Integrated six sources of health data
Apple HealthKit, Android Health Connect, Google Health, Garmin, Strava and Fitbit. Two push from the phone and four are pulled on a schedule, so the platform reconciles a participant's day from whichever source she actually uses, and a device change does not cost her the record.
Built leaderboards that scope the way the events do
Overall, by city, by training group, and by period — yesterday, weekly, monthly. Ranking rules are implemented once on the server and never recomputed on the handset, so every participant's position is derived the same way.
Automated the certificates
Weekly, monthly and post-event certificates are generated server-side from the participant's own record, with an organiser switch to hold them back until an edition is ready to issue them.
Rebuilt notifications with real per-participant state
Announcements can be addressed to a whole event or to one city or training group, and read state is kept per person on the server rather than guessed on the device — so reinstalling the app or changing phone does not resurface everything ever sent.
Gave organisers an admin panel for the things they actually change
Events and their rules, participants, approved-participant lists, leaderboards, notifications, certificates and sponsor placements — each scoped to one event, so an organiser managing one edition cannot reach another.
Wrote the API as a versioned contract
The app and the backend are built against a written, versioned specification rather than against each other, which lets the mobile and backend work proceed in parallel and makes every change to the shape of a response a deliberate, recorded decision.
Put both sides under automated tests
548 tests on the app and 305 on the backend, with the rule that a feature whose trigger is a widget is not considered tested until a test has pumped that widget.
Managed the releases
Versioned builds, signed with the correct per-brand upload key, submitted and tracked on both the App Store and Google Play, with a server-side force-update gate that is only armed once the new build is confirmed live on that platform's store.
Results
- 21 events5 brands, one codebase
- A new edition is configured, not forked. The platform has absorbed events judged on three different scoring models without a separate app or a separate backend for any of them.
- 14,989Participants carried
- The same app and the same backend serve every edition, including events running concurrently with live participants on each.
- 853Automated tests
- 548 on the app and 305 on the backend, ensuring that shipping for one event does not break another that is mid-challenge.
Next case study
All case studiesReady to Get Started?
Let's Build Something Amazing Together
Transform your digital presence with our expert team. From concept to launch, we're with you every step of the way.