DevoraX is a two-person studio that builds competition and leaderboard software for functional fitness. We have shipped one: WOD Pro League, a Flutter athlete app on iOS and Android, a React organizer dashboard, and a Node.js backend where scoring and ranking are computed server-side. The client reports 12,778 athletes and 8,567 submitted scores. Founded 2019, fixed-price, case study published.
What do you actually ship in a competition and leaderboard app?
A base build is three surfaces on one backend. Athletes get a Flutter app compiled to native iOS and Android from a single codebase and submitted to both stores. Organizers get a React dashboard for creating events, defining divisions, publishing workouts, reviewing submitted scores and managing qualification. Both talk to a Node.js service layer where the scoring and ranking logic lives.
That last point is the whole design. Ranking is never computed on a phone. A leaderboard calculated client-side is a leaderboard that can disagree with the phone next to it, and in competition that disagreement becomes a dispute. Centralising ranking gives one authoritative answer that every client renders identically, and it lets competition rules change without an app store release.
Real-time delivery runs over persistent Socket.io channels rather than polling, so a submitted score propagates as an event instead of on someone's next request. Ranked score data sits in Redis, so position and range queries are answered in memory instead of re-sorting a relational table on every submission.
Who is this built for?
Anyone whose product is a ranking. Online qualifiers, multiple divisions, workouts released on a schedule, scores submitted against a deadline, a qualification cut at the end. If the standings are wrong or late, nothing else about the app matters to an athlete.
We have built that shape once, for one operator. The WOD Pro League record does not describe its client as a federation, a gym chain or an event organizer, so we do not list them as segments we serve. What the record does state is the problem the build addressed: athletes lacked a comprehensive platform to compete across global regions with real-time tracking and analysis. That platform runs global online competition, and that is the shape we can show you.
Be honest about your own scale on the discovery call. A one-off throwdown for a single affiliate does not need Redis, Socket.io and a serverless backend, and we will tell you so. This architecture earns its cost when submissions arrive in deadline-hour bursts rather than a trickle.
Which build proves you have done this before?
One build, and it is public. WOD Pro League is a global functional fitness competition platform: a Flutter app on the App Store and Google Play, a web platform at wodproleague.es, a React administrative dashboard, and a Node.js backend on AWS with Redis and Socket.io handling real-time data.
The client reports 12,778 total athletes and 8,567 submitted scores, competitions listed as 24/7 active, a 68.3% qualification rate, and reach across more than 120 countries. Those are the client's figures, not measurements DevoraX took or audited. The one that carries technical weight is the submitted-score count, because every entry is a write that had to be accepted, ranked and pushed out to connected clients without breaking the integrity of a live leaderboard.
You do not have to take any of this on description. The web platform, the iOS app and the Android app are all live and inspectable, and the full engineering case study is published on this site at /projects/31.
How does the leaderboard hold up at a submission deadline?
Competition traffic is not flat. It clusters around workout releases and submission deadlines, then falls away between events. The peak decides whether athletes trust the platform.
Three decisions carry that load in WOD Pro League. Redis holds the ranked score data, because a leaderboard is a ranking query and re-sorting a primary database on every submission does not survive a burst. Socket.io replaces polling with persistent push channels, and its transport negotiation and reconnection matter because athletes move between cellular and wifi mid-session. AWS Lambda scales out per invocation and back down afterwards, so capacity follows the competition calendar rather than a fixed fleet sized for the average.
We publish no concurrency, latency or throughput figures and will not estimate any; the only counts in the record are the client's, and they are cumulative totals, not peak load. Timing is the quieter problem: deadlines are held in absolute time on the server and shown in local time in the client, so a cutoff means the same instant everywhere.
How separate are the athlete side and the organizer side?
Separate clients, one shared backend. Three client surfaces, the Flutter athlete app, the web platform and the React administrative dashboard, sit on one Node.js service layer. The athlete app submits and displays. It cannot compute or alter a rank, because the scoring and ranking logic lives on the server, which is what makes every surface agree.
Be clear on what that is: separation of surfaces and of authority, not of data. We have published nothing on roles, permissions, row-level access or anti-cheat for WOD Pro League, so we will not describe an access model we cannot evidence. Server-side ranking alone does not stop a tampered client posting a false score through the same API; submission validation and judging do, and both are rules you define.
If you need a written access model, or several organizers running isolated competitions from one instance, raise it on the call. Role-separated dashboards over one shared backend is a pattern we describe on our multi-vendor marketplace development page, at /solutions/multi-vendor-marketplace-development.
What does the build process look like, and what do you need from us?
It starts with a free 30-minute discovery call and ends with a written fixed-price proposal before any code is written. We do not bill hourly. The proposal names what is in scope and what is not, because a fixed price is only meaningful if both halves are written down.
What we need from you is your rulebook, written down. Scoring formats per workout type, how divisions are structured, tie-break rules, what counts as a valid submission, and the qualification criteria. Those are the requirements the ranking pipeline is built from. Vague answers here are the most reliable cause of rework later.
Practically, we also need brand assets, and an app store release needs Apple Developer and Google Play accounts. Whose accounts those are, and whose cloud account the backend runs in, is settled in the proposal rather than assumed in either direction, so decide it before the first release instead of after it. If judging involves video review, show us how you judge today.
How is this priced?
Fixed price, after the discovery call, in writing. Published tiers start at $2,900 for MVP Starter and $7,500 for Growth, with Enterprise custom-scoped. Those are indicative starting points rather than quotes, and a competition platform with real-time ranking, an organizer dashboard and two app store releases sits above an MVP Starter number.
The honest driver of cost is not screen count. It is how complicated your scoring rules are and how many of them there are. One workout type with a single ranking formula is a small build. Points tables across multiple divisions, scaled and prescribed categories, tie-breaks resolved on secondary fields, and a qualification cut with manual overrides is a much larger one, because each rule is logic that has to be correct when an athlete challenges a placement.
You get the number once we have read your rulebook. If scope changes during the build, it is re-quoted in writing rather than absorbed quietly and recovered elsewhere.
What happens after launch, and who owns the code?
You own all code and IP on final payment. That covers the Flutter app, the backend services, the admin dashboard and the infrastructure configuration. That transfer is the commitment we publish, and it is the one worth holding us to in writing.
Support after handover is scoped and quoted separately rather than assumed. Competition platforms have a particular operational shape: the risk is concentrated into a few hours around a deadline, so the useful question is not a generic uptime promise but who is reachable during your qualifier window and how you reach them. Settle that before your first event, not during it.
DevoraX is two people, Sameem Amjad and Usman, working since 2019 across 25 delivered projects, every one with a published case study. Price that constraint in. It also means the people who wrote your ranking pipeline are the people who answer when it misbehaves.
When should you not hire DevoraX for this?
Do not hire us for on-site live event production: heat scheduling against physical floor lanes, judge tablets running offline in a venue with no signal, arena screen graphics. We have shipped online competition with real-time leaderboards. We have not shipped venue floor operations, and buying that from a team learning it during your event is a bad trade for both of us.
Skip us too if you need coverage in your timezone on a rota, or an agency with a bench it can surge onto a fixed event date. Two people cannot honestly promise either.
And if you only need scoring for one gym's internal throwdown, a spreadsheet or an existing off-the-shelf scoring tool will beat a custom build on both cost and time to your first event. Come back when you are running qualifiers at a scale that breaks them.
Start with a scoping call
A free 30-minute call to work out what you are building and what is actually hard about it. If there is a fit you get a written fixed-price proposal. If there is not, we will say so on the call.
Book a call