Atafen — Education Platform & CMS
Atafen is a production-oriented full-stack platform for an education institution, combining a responsive public experience, authenticated content management, and a Supabase-backed data layer inside a single Next.js application. The architecture separates deploy-time brand identity from runtime institutional content, allowing the core product to be adapted to other education organizations while preserving a custom visual identity for each deployment.
- Record
- Project 022
- Documentation
- Technical notes included
A production-ready digital platform built for Atafen Eğitim Kurumları in Malatya, combining a high-quality public-facing education website with a secure, data-driven content management system. The platform gives students and parents a clear way to explore academic programs, verified student achievements, announcements, institutional information, and direct contact channels, while authorized staff can manage time-sensitive content through a protected administration interface. Built as a single full-stack Next.js application backed by Supabase, Atafen uses PostgreSQL, authentication, object storage, Row Level Security, schema-driven validation, and server-side rendering to keep public content fast, maintainable, and secure. The architecture also separates brand configuration from operational content, making the system adaptable to other education institutions without turning the product into a generic template. The project was designed around real production constraints: responsive UX, controlled publishing workflows, student-media consent requirements, secure admin authorization, structured content management, deployment portability, automated quality checks, and long-term maintainability.
System components
- Public Experience — Server-rendered pages for academic programs, verified student achievements, announcements, institutional information, contact details, WhatsApp and location-based conversion flows.
- Admin CMS — Protected management interfaces for announcements, success stories, institutional settings, contact information, social links and program presentation overrides.
- Supabase Data Layer — PostgreSQL for structured content, Supabase Auth for administrator identity, Storage for managed public media and SSR-aware clients for authenticated server workflows.
- Authorization & Security — Row Level Security on exposed tables, explicit admin-role verification, server-side mutation checks and restricted Storage policies provide defense in depth.
- Publishing Workflow — Content supports controlled publication states so draft, scheduled, published and archived information can be separated from what anonymous visitors are allowed to read.
- Media & Consent Controls — Student success media is handled through structured Storage paths and publishing rules designed around explicit consent, file validation and descriptive alternative text.
- White-label Architecture — Institution identity, typography, design tokens, logos and metadata defaults are deployment configuration, while operational information remains database-managed.
- Design System — Responsive Tailwind CSS and shadcn/ui-based interface architecture with reusable primitives and institution-specific visual direction rather than a generic education template.
- Validation Layer — Zod and TypeScript provide typed boundaries around user input, administrative mutations and application data contracts.
- Delivery & Quality — Standalone Next.js production output, multi-stage Docker deployment, health checks and a pnpm quality gate covering ESLint, TypeScript, Vitest and production builds.
Data under tension
Anonymous visitors request server-rendered Next.js routes that read only publicly permitted content from Supabase. Database Row Level Security prevents anonymous access to unpublished or privileged records. Administrators authenticate through Supabase Auth and access protected management routes; validated server-side actions perform content mutations while authorization checks and RLS independently enforce permissions. Uploaded media is stored in controlled Supabase Storage paths and referenced by the application through database records. Publishing or archival changes invalidate the relevant public views so visitors receive the current approved content.
Tradeoffs
- Brand identity is intentionally configuration-driven rather than editable from the CMS, so deploying a substantially different institution requires a controlled configuration and asset update followed by a new deployment.
- Student achievements and media depend on operationally correct consent and content-entry processes; technical restrictions reduce risk but cannot replace institutional approval workflows.
- The current program model favors curated configuration and presentation overrides; a future multi-tenant or heavily dynamic deployment may benefit from promoting programs into a more comprehensive independently managed CMS domain.