Language-School Platform

Small academies run on glued-together tools: a website here, a spreadsheet of students there, a separate scheduler, a mailing app, a design tool. Nothing talks to anything else — and the public site goes stale the moment class data changes.

This platform collapses all of that into one system: a polished public site that markets courses and enrols students, and a comprehensive admin the staff run the school from. The two halves share the same data, so the front of house is never out of date with the back office.

It is a product, not a one-off website. Enlil Academy — a language & IT school in Iraq — is its first live deployment.

The problem

A school's information lives in too many places. The catalogue on the website is a hand-maintained copy of what's actually being taught. Attendance is a spreadsheet. Enrolment is a DM. When something changes, half of those surfaces quietly fall out of sync, and the public site is usually the last to catch up.

What I built

One system where the public site is driven by the same data the staff manage. Publish a course or award a badge in the admin, and the public pages reflect it immediately. It covers the whole student lifecycle:

1. Discover a course on the public site
2. Take a placement test
3. Sign up as a guest
4. Get approved into a class
5. Attend, and earn badges along the way

The public catalogue is grouped by CEFR level and rendered straight from the CMS, so it can never drift from what the school actually offers.

The back office

This is where most of the engineering went. The admin is a full operations tool, not a thin wrapper over a database.

• Content management (CMS) — pages → sections → content items, each with publish / draft states, filtering and search. It's the backbone the whole public site reads from.
• Scheduling calendar — a week view with per-session attendance, rescheduling and overlap stacking. The hardest interactive surface in the build.
• Analytics — traffic, engagement and visitor geography, with admin traffic excluded automatically.
• Badges & gamification — awardable badges with drag-to-order, granted to students inline.
• Built-in CRM — pick recipients, choose a template, preview the branded email.
• Role-based access (RBAC) — fine-grained per-resource permissions, with a head-admin bypass.

Permissions are real, not decorative. Each sub-admin gets create / update / delete / approve rights per resource, and the head admin bypasses the matrix:

// A sub-admin's rights are a per-resource bitmask; the head admin short-circuits.
func (u User) Can(action Action, resource string) bool {
    if u.Role == RoleHeadAdmin {
        return true // head admin bypasses the permission matrix
    }
    perms, ok := u.Grants[resource]
    return ok && perms.Has(action)
}

Why it holds together

The single-system bet is the whole point. Because the public catalogue, the scheduler, the CRM and the analytics all read and write the same records, there is no sync step to forget. A change in the admin is, by construction, live on the public site — no copy-paste, no stale page, no second source of truth.

That's what makes it a platform rather than a website: point it at a different school's data and it runs that school instead.