SCOUT ASCCI — Educational tracking for a scout movement

SCOUT ASCCI — Educational tracking for a scout movement — Paterne SEKA

Problem

Tracking scouts — membership, attendance, progress, fees, documents and parental permissions — has to be shared between leaders, parents and officials, with personal and medical data to protect.

Context

Platform for the Catholic scout movement of Côte d'Ivoire, used first by parishes, then by districts, with an organisation designed to reach the regional and national levels.

Goals

Centralise scout tracking for each parish
Give each person (leader, parent, official) access that matches their role
Prepare the extension to district, regional and national levels

Constraints

Personal and medical data of minors
Each installation keeps its own data, which never flows to another one
A single platform administrator for several installations

Solution

A single API deployed once per platform, each with its own database, file storage and secrets, and dedicated interfaces for parishes and districts. Shared business rules (roles, branches, validation) are used by both the API and the interfaces.

Key features

Scout, parent and emergency contact records, with CSV import
Activities, meetings and attendance, with QR-code cards
Progress and badges by branch
Fees and camp permissions
Programmes and calendar
Documents stored privately, served after an access check
Dashboards, reports and audit log

Users

Group and unit leaders
Parents
District officials
Platform administrator

My role

Architecture design (monorepo, standalone installations)
Development of the NestJS API and Next.js interfaces
Data modelling with Prisma and PostgreSQL
Authentication, sessions and role-based authorisation
VPS deployment, encrypted backups and continuous integration

Architecture

pnpm monorepo: a NestJS API (Prisma, PostgreSQL), the only component with database access, and two Next.js interfaces (parish and district) that relay calls server-side on a single origin. Files are stored on Cloudflare R2 in a private and a public space.

Browser

Nginx

reverse proxy

Next.js

parish or district space

NestJS API

Technical decisions

Short-lived access token (5 minutes) and revocable rotating session, in httpOnly cookies
Platform administrator tokens signed with ECDSA, verified by other installations with the public key only
Every API route protected by default, with public routes explicitly justified
Encrypted backups (AES-256-GCM) every night and before each migration

Challenges

Fully isolating each installation's data
Letting a single administrator act on several installations
Protecting personal and medical data of minors

Outcome

Parish platform and district application built on a shared codebase
Lint, types, unit tests and build checked on every change by continuous integration

Next steps

Opening to the regional and national levels

Digitising the educational tracking of a scout movement

An organisation with several levels to equip?