KaSkwela

I designed and developed KaSkwela around a complete classroom journey: helping a teacher prepare and teach a lesson, and helping students join and participate. The application brings classroom communication, learning resources, live teaching, controlled speaking, a collaborative whiteboard, and participation-based attendance into one workspace.

Rather than building a general-purpose community platform or a full learning management system, I focused the product on activities that directly support teaching. The current documentation describes implementation through the core classroom phases, while provider integration, device acceptance, and release hardening remain ongoing.

The central product question was how to keep communication, teaching, participation, and attendance coherent without making the classroom unnecessarily complex. A lesson needs a clear preparation, participation, and review flow, with permissions that reflect different responsibilities.

These priorities come from the product specification, not a claimed interview or survey study. The MVP deliberately excludes a full gradebook, payments, parent portals, public community discovery, student direct messages, automated proctoring, and face-recognition attendance.

As the solo designer and developer, I worked across product planning, interface design, architecture, and full-stack development. I translated the classroom workflow into role-aware screens and defined the boundaries between persistent records, realtime events, live media, and collaborative drawing.

My development approach favors complete vertical slices. A feature connects the interface, validation, authorization, persistence, success and error feedback, and meaningful verification before its scope expands. Changes to a permission or contract also need corresponding documentation updates.

The visual direction is friendly and academic: blue accents and light everyday workspaces, with darker presentation surfaces for live teaching. On desktop, grouped room navigation provides context; on mobile, a single main pane and drawers or sheets keep the task readable.

The classroom loop begins with trust. Teachers verify their email and submit private verification evidence before creating a classroom. Students enter through an invite and a validated membership operation. Platform role and classroom membership remain separate: an administrator does not automatically receive teacher controls.

During a lesson, students subscribe to media by default. Raising a hand requests permission; the teacher grants or revokes microphone publishing, and the student still chooses whether to turn their microphone on. The shared whiteboard has teacher-only, collaborative, and read-only modes.

Next.js, React, and TypeScript support the application interface and protected operations. Better Auth establishes identity, while Prisma and Neon PostgreSQL hold persistent classroom records. Socket.IO and Redis handle realtime coordination, LiveKit transports media and enforces publishing capabilities, tldraw synchronizes drawing, and private S3-compatible storage holds files.

The architecture separates workloads by their needs. High-frequency drawing should not compete with chat events, media transport should not become the durable attendance record, and a failure in an optional subsystem should not block unrelated classroom actions.

The documentation describes substantial progress across the classroom workflow. It does not establish a fully accepted MVP, production uptime, measured performance gains, or user impact. Actual services and devices are still needed to validate the behavior described by the implementation notes.

The verification strategy prioritizes teacher gates, invitation integrity, message retries, actual media permission changes, attendance event replay, private resource access, and whiteboard modes. Mocked providers or skipped credential-dependent suites cannot establish real-service acceptance.

KaSkwela reinforced that permissions are part of the product experience, not just backend rules. Teacher verification, classroom ownership, and student participation influence both the interface and the systems beneath it. A complete preparation-to-review flow matters more than a long list of disconnected features.

The next milestone is validating the complete classroom loop with actual services and devices, closing operational and recovery gaps, and completing the PWA foundation. Optional AI assistance comes after classroom stability, with source grounding and access isolation.