Enterprise2023

Krida AI

National Sports Management Platform

National sports management platform serving 1.4M+ registered athletes, coaches, and federation administrators across 28 disciplines.

Headline outcome

1.4M+ registered users · 99.97% uptime · selection time reduced 6 weeks → 4 days

Runners spread across the lanes of an athletics track, seen from above — Illustrative photography. No imagery on this site is from a client environment.

Next.jsFastAPIPostgreSQLReact NativeAI AnalyticsKubernetes

Overview

India's largest sports federation needed a unified platform to manage athlete registrations, competition results, coaching certifications, selection processes, and performance analytics across 28 disciplines.

Challenge

The scale was unprecedented — 1.4 million registered users, 28 sports disciplines, 600+ clubs, and federation administrators across every Indian state. The legacy system was a combination of paper records and disconnected spreadsheets. Data integrity and concurrent load were the critical risks.

Solution

We built Krida AI on Next.js and FastAPI with a PostgreSQL backend sharded by discipline. AI-powered athlete performance analytics used historical competition data to generate selection recommendations and injury risk scores. Mobile apps for athletes and coaches on React Native. Role-based access for 8 user types.

Outcome

1.4M+ registered athletes. 99.97% uptime across 3 years. Selection process time reduced from 6 weeks to 4 days. 40% reduction in federation administrative overhead. Winner of Sports Technology Innovation Award 2023.

Measured

1.4M+

registered athletes, coaches and administrators

99.97%

uptime over three years

disciplines on one platform

6 wks → 4 days

selection cycle

The constraint that shaped it

The record decides who competes. That is the constraint: a selection is consequential and contested, so correctness under concurrent write mattered more than read throughput, and every change to an athlete record has to be attributable afterwards. Separated role types, discipline-specific configuration on one schema, and an audit trail held on the record rather than on the request all follow from it — as does reporting uptime across three years instead of across a favourable quarter.

How it was built

How the uptime figure was earned

99.97% over three years is a different claim from 99.97% in a good quarter, and the load behind it is not evenly spread. A national platform sits quiet for weeks, then a selection window opens and every state files on the same afternoon. So it was sized against that afternoon rather than against an annual average: PostgreSQL sized for concurrent write, a load-testing method built around the peak, and headroom proven before a window instead of discovered during one. Uptime is reported monthly under an SLA, from the platform’s own figures rather than from a status page.

Who is actually at the keyboard

1.4 million accounts is not one audience. An athlete uploads a document once a season, on a phone. A coach works a squad list. A federation administrator runs a selection. A club secretary — the person who does this least often and matters most to the record — enters results on someone else’s behalf. Role types are separated in the permission model rather than in the interface, so what a user can change is a property of the schema. The four-day selection cycle came from removing paper handoffs, not from a faster model.

Releasing into a live platform

There is no maintenance window during a selection. Work runs in fortnightly cycles with a live demo at the end of each, and releases are migration-first: the schema change ships and is verified before the code that depends on it, so a rollback does not strand data. Unit coverage holds to an 80% floor and every release carries notes. Twenty-eight disciplines also means a change to shared scoring logic is regression-tested across all of them, because the discipline nobody thought about is exactly where a defect surfaces.

What was hardest to get right

Not scale — reconciliation. Twenty-eight disciplines seed, score and categorise differently, and each had its own paper conventions before the platform existed. The choice was one schema with discipline-specific configuration, or twenty-eight forks that would drift apart within a year. We took the first, which made the modelling slow and the maintenance cheap. The other hard part was history. Legacy records arrived as paper and disconnected spreadsheets, and a migrated record that cannot be traced back to its source is worse than a missing one, because a selection will be run on it.

Stack, by concern

Application

Next.jsReact NativeTypeScript

Backend & data

FastAPIPostgreSQL

Analytics

Performance analyticsSelection supportHistorical competition data

Runtime & control

Role-based accessRecord-level audit trailSLA-backed operations

More work

Project GARRISON

AI-Augmented HRMS for Defence Personnel

EMSPL Fleet Intelligence

AI Fleet Management for 2,400 Vehicles

All case studies Start a project