Socio Kolab
A white-label portal that replaces the spreadsheets and group chats student societies run on — member lifecycle, dues tracking, and events with public custom registration forms, each club branded under its own URL and colors.
01. The Problem
Student clubs run on a fragile mix of WhatsApp groups, forgotten Google Forms, and a spreadsheet only one exec understands. Membership records, dues collection, and event turnout are scattered — and every year, leadership turnover wipes the club's institutional memory.
02. The Logic
Scoped v1 to the three highest-pain modules (members, dues, events) and cut everything else to protect adoption.
Chose a deliberately boring single-codebase stack — full-stack Next.js with Server Actions over a separate Django API — because solo maintainability, not traffic, is what kills student-built tools.
Designed multi-tenant from day one (club-scoped tables, user/membership split, config-not-code) while deploying single-tenant, so multi-club support later became an additive migration instead of a rewrite.
Rejected an encrypted-ID URL scheme in favor of real isolation: human-readable club slugs, with every query compound-scoped by id and clubId and authorization checked in every server action.
Modelled dues as immutable period-scoped records and guests as membership-less attendees, keeping history auditable across academic years and unifying member/guest reporting.
03. The Stack
04. The Solution
Implementation Result
A multi-tenant platform where each club gets a branded portal at its own slug: role-based member management with an approval pipeline, period-scoped dues tracking with CSV export, and events with a drag-and-drop custom form builder whose public registration links accept members, non-members, and anonymous visitors — all validated server-side against each event's form schema. A theming engine derives a ~25-token design system from three club-chosen colors, with luminance-based dark-theme detection and server-side WCAG contrast validation.
Key Outcomes
- 01.Adopted by 2 clubs / over 100 members
- 02.3 user-chosen colors expanded into ~25 derived design tokens per club
- 03.Cross-tenant isolation verified by adversarial tests on every resource type
Reflection
- ID obscurity is not access control — per-query authorization scoping is what actually isolates tenants.
- Cheap future-proofing (a clubId on every table) beats expensive future-building (tenant onboarding before tenants exist).
- Constraining user input — three colors, five field types — is what makes guaranteed-good output possible.
- Keying stored data by immutable ids instead of editable labels keeps history intact through every rename and delete.