A two-sided platform for a martial arts federation

What it is

A two-sided platform for a martial arts federation that operates in several countries. On one side, the CRM and management system the federation runs on: student enrolment, rank progression, instructor management, regional administration, financial oversight and live analytics for leadership. On the other, an app for the students themselves, where each one follows their own progression. Both sides read and write the same database, under the same permission rules.

The problem

Federations are hierarchies with hard data boundaries. A regional director must administer their own country and must not see another country’s students, finances or instructor records. A student, in the app, sees their own progression and nothing else. And these boundaries have to hold in an app open to every student, not only in a back office used by staff. Global leadership needs an accurate roll-up across all of it. Get the boundary wrong and you have either a useless system or a data leak. So the boundaries live in the database, as row level security policies, not in the interface.

The hard part

The dashboard first shipped on mock data, the standard trap in role-partitioned systems: the numbers look right until real permissions apply, and then every figure is wrong in a different way per role. Rebuilding the analytics against live queries meant every metric had to be correct under three visibility scopes at once. A director’s student count and the super admin’s student count are different numbers, both correct, and the system has to know which one it is answering.

The second lesson was persistence discipline. Early student data lived in component state and evaporated on refresh. Moving it into Postgres behind proper migrations was not a feature. It was the point at which the thing stopped being a prototype.