Sinergi 9D — A Class Administration System for SMP N 1 Cawas, Built to Scale Beyond One Classroom

A class administration and monitoring system built for a real homeroom teacher at SMP N 1 Cawas — attendance, literacy & numeracy assessment, and a teacher–student–parent communication hub — shipped as a 1-week MVP with a multi-tenant RBAC architecture designed so any other classroom could onboard without a rebuild. Currently mid-validation: built and self-tested, pending structured user testing with the teacher, students, and parents.

TL;DR

Sinergi 9D replaces a homeroom teacher's manual, scattered class administration — attendance, grades, literacy/numeracy tracking, and parent communication — with a single system. Requested by a real teacher at SMP N 1 Cawas, it shipped as a 1-week MVP using an AI-assisted ("vibe coding") workflow. Unlike a one-off build for a single class, the system was deliberately architected as multi-tenant from day one: a Super Admin can onboard any other homeroom teacher's class without touching code.

• Role: Solo — discovery, architecture, full-stack development, QA
• Tools: Lovable, GitHub, Zed (opencode agent), Vercel, PostgreSQL (Neon) + Drizzle ORM
• Duration: 1-week MVP sprint
• Status: 🔲 MVP built and self-tested; structured user testing (teacher → students → parents) not started yet — pending the teacher's schedule

Context

A homeroom teacher (wali kelas) at SMP N 1 Cawas asked for an LMS for her class. In the kick-off meeting, the actual need turned out to split into two distinct modules:

1. Administrasi Kelas — day-to-day class operations
2. LMS — a Google Classroom-style teaching/learning layer (materials, assignments, quizzes)

The product was later formalized under the name Sinergi 9D — early on it was informally referred to as "LMS SMP N 1 Cawas," a name that stuck around in some documentation even after the module split made it inaccurate.

Problem

With only 1 week available for a first MVP, both modules couldn't ship together. The kick-off surfaced three concrete needs specific to running the class day-to-day — separate from the teaching/learning need "LMS" originally implied:

Constraint

• 1-week deadline for a working MVP — a hard cutoff, not a soft estimate
• Solo, end-to-end delivery — one person covering discovery, architecture, and full-stack build
• AI-assisted ("vibe coding") workflow — Lovable for the initial build, then human-in-the-loop refinement via an AI coding agent
• No formal usability testing yet — self-tested against a personal test-case checklist; structured testing with real users (teacher, then students, then parents) hasn't started
• Scope trade-off, made deliberately — LMS (the Google Classroom-style teaching layer) pushed to Phase 2 so the 1-week window could go entirely to Administrasi Kelas

Approach

1. Request — teacher asks for an LMS for her class
2. Kick-off meeting — discovery reveals the request is really two modules: Administrasi Kelas + LMS
3. Scope decision — 1 week isn't enough for both; commit fully to Administrasi Kelas, defer LMS to Phase 2
4. Simple architecture design — plan the RBAC model (Super Admin → Admin Kelas → Murid/Ortu) before writing code
5. Build in Lovable — generate the first working version
6. Push to GitHub — pull the generated codebase out of Lovable
7. Refine in Zed (opencode agent) — clean up and extend the code with an AI coding agent
8. Deploy to Vercel
9. Audit/review — check the shipped build against the intended scope
10. Self-testing — run through test cases personally, role by role (Super Admin → Admin Kelas → Murid → Wali Murid)
11. 🔲 Next: structured user testing — teacher first, then students, then parents — not yet started

Solution

Sinergi 9D's Administrasi Kelas module runs on four roles: Super Admin, Admin Kelas (homeroom teacher), Murid, Wali Murid. Since the fastest way to show v1 of this MVP is to watch it move, each role below gets a short explanation first, followed by a video walkthrough instead of static screenshots — recorded on an isolated demo dataset (a seeded "Kelas Demo 9X" with fictional students), not real student records.

A quick-reference map of what each role can do and see, before the role-by-role breakdown below.

1. Super Admin

The onboarding entry point: create Admin Kelas accounts, manage academic years (one active at a time) and classes school-wide — so a new homeroom teacher's class can go live without touching code.

2. Admin Kelas (Homeroom Teacher)

The core of the MVP: class profile and student roster, schedule, daily attendance, seating chart, class rules, official documents (SK, Program Kerja, Struktur Organisasi), inventory, cleaning-duty roster, announcements, teacher notes, literacy journal review, monthly stats, and the gradebook ("Leger Nilai") — all scoped to that teacher's own class.

3. Murid

Read access to the same class data (schedule, rules, seating chart, organization structure, inventory, cleaning duty, announcements, and notes from the teacher), plus what's theirs alone: submitting literacy journals and tracking their own attendance and grades.

4. Wali Murid

A narrower, read-only lens into one child's progress — attendance, grades, teacher notes, and literacy history — with zero visibility into other students' data or other parents.

Role-based access, built for reuse

Built mobile-first for the roles that need it

Murid and Wali Murid are the two roles most likely to open Sinergi 9D from a phone, not a desktop — a student checking today's schedule between classes, or a parent glancing at attendance on the way to work. The interface was built responsive with that access pattern in mind, instead of defaulting to a desktop-only admin dashboard and treating mobile as an afterthought.

The Strength

The original request was for one teacher, one class. Instead of hardcoding that assumption, the RBAC layer was built as if a second teacher would show up tomorrow: Super Admin → Admin Kelas → Murid/Ortu, with credential generation cascading down each level.

Build once, use many times — the next homeroom teacher who wants this doesn't need a rebuild, just a new Admin Kelas account.

That's a bet made before any second teacher actually asked — spending part of the 1-week budget on structure that only pays off if the product gets used beyond this one class.

The same instinct shows up one layer up, in how the codebase itself is documented: alongside the app, there's a standalone reference doc — schema, routes, auth flow, and domain-specific gotchas — written so an AI assistant can understand and audit the whole system without opening a single file. Same principle, applied to maintenance instead of onboarding: build the context once, reuse it for every future review or handoff.

Result

Open Items

• 🔲 Run user testing: teacher → murid → ortu
• 🔲 Capture real pain points from the kick-off meeting to replace the scaffolded Problem section
• 🔲 Decide whether/when the LMS module (Phase 2) gets scoped

Learning

The clearest lesson from this project was less about code, more about translating an unclear request into a buildable one — a skill that mattered more than any single technical decision:

1. Read past the literal ask — "I want an LMS" wasn't the real requirement; it was a label the client used for a need she hadn't fully unpacked yet. The actual need only surfaced through the kick-off conversation.
2. Organize it back into something decidable — turning that vague ask into two clearly separated, scoped modules (Administrasi Kelas vs. LMS) so the client could make an informed choice instead of staying stuck on an ambiguous brief.
3. Recommend, don't just present options — pairing the scope split with a clear suggestion (build Administrasi Kelas first) and the reasoning behind it, rather than leaving the decision entirely on the client's plate.
4. Build fast once scope is locked — the 1-week timeline only worked because the ambiguity got resolved before development started, not somewhere in the middle of it.