AWS Builder Center

Builder Center

Present Sir: a college attendance planner that answers "how many more classes can I skip?"

Present Sir: a college attendance planner that answers "how many more classes can I skip?"

Present Sir is a Next.js 16 + Postgres web app for Indian college students and class representatives: deterministic attendance math (safe skips, recovery, leave planning), a shared lecture log that answers "what was taught today," and a semester planner. No AI, no black box; the formulas are small, tested, and in the repo.

Vivek

Present Sir — Built for Kiro Build Challenge

Present Sir is a responsive web app for Indian college students and class representatives that answers two questions that come up every semester: "How many more classes can I skip and still make 75%?" and "What was taught today?" It pairs a deterministic, fully tested attendance engine with a shared classroom featuring a lecture log, a semester planner, and search across notes and previous-year questions. No AI runs inside the app. Kiro, the AI IDE, is what helped build it.

PROBLEM STATEMENT

Every semester, the same two questions float around every Indian college group chat:
  • "Bhaiya, kitni class aur chhod sakte hain?" How many more classes can I skip and still make the 75%?
  • "Aaj class mein kya padhaya tha?" What actually got taught today, because I was out?
The first has no good answer because attendance math is left to spreadsheets and guesswork, and CR-cancelled classes silently corrupt everyone's percentage. The second has no answer at all: notes and topics live scattered across chats, and a student who missed three days has no reliable way to catch up.

SOLUTION & WHAT WE BUILT

I built Present Sir to answer both. No AI. I mean that about the app itself. There is a fashionable way to build this: feed the attendance sheet to a model and let it "reason" about your risk. I didn't. The answer to "how many classes can I skip?" is closed-form arithmetic, and closed-form arithmetic is either right or wrong. A language model has no business between a student and a$\text{floor}()$function.
For$A$attended classes out of$T$total, with minimum percentage$m$:
  • current percentage:$\frac{A}{T}$
  • safe skips:$\text{floor}\left(\frac{A - m \cdot T}{m}\right)$
  • recovery:$\text{ceil}\left(\frac{m \cdot T - A}{1 - m}\right)$, the number of consecutive classes you must attend to get back to the minimum
Take 18 attended out of 20 at a 75% minimum. You sit at 90%, and each skip costs 5 points (one of 24 total), so you can skip 4 and land exactly on 75%. The engine says 4. A model has to do that division itself, and sometimes it won't.
All of this lives in one module, src/lib/attendance-engine. Plain TypeScript, no dependencies, and a node:test suite that pins down the cases that break naive implementations: zero classes so far (no percentage, no division by zero), exactly at / just below / just above the minimum, a 100% minimum where recovery is mathematically impossible (the app says so instead of showing infinity), cancelled and holiday classes that never enter the denominator, medical leave that counts as attended only if your college policy says so, and extra classes that count as attended.
The math was the easy half. The hard part is that attendance is a group activity. When the CR cancels a class, cancelClassAction writes a cancellation record, flips every member's entry for that slot to cancelled, and posts to the classroom feed. That class then leaves everyone's denominator, not just the CR's. Get this wrong and half the section's numbers drift apart silently, and nobody notices until the percentage check at the end of the semester.
The lecture log has four permission modes: cr_only, cr_contributors (the default), open_approved (anyone posts, entries wait in an approval queue), and open. The check happens server-side in canCreateLectureLog() on every write, because hiding the "Post" button is not a permission system. Each log entry links a topic to its notes, previous-year questions, and a missed-class catch-up card. That is the "what was taught today" answer, and it's also what makes the app useful to a student who missed three days last week.

The rest of the app:

  • /home shows today's classes with one-tap Present / Absent / Cancelled, attendance risk (worst first), due-soon items, the next exam, and catch-up cards
  • /what-if has live sliders; move them and the numbers move, no Calculate button
  • /leave and /forecast plan cumulative leave and project the end-of-semester percentage
  • the planner shows month and week views merging classes, assignments, exams, personal events, and leave plans
  • /search covers lecture logs, resources, PYQs, assignments, exams, and announcements
  • settings cover English + हिंदी, the attendance threshold, motion on/off, and JSON export

HOW WE USED KIRO

Kiro did the heavy lifting on structure and first drafts. The project scaffolding (Next.js 16 App Router, Drizzle schema, Tailwind v4 setup) came from Kiro, which cut hours of boilerplate inside a hard 18.5-hour window. I prompted Kiro for a first draft of the attendance engine, but the formulas it produced went through hand verification: each one was checked against hand-computed cases and then pinned by the node:test suite in src/lib/attendance-engine/__tests__/attendance-edge.test.ts style assertions (zero classes, exact minimum, 100% minimum, cancelled/holiday exclusion). Kiro also helped prototype the /what-if live-slider interaction and the four-level landing page motion system; the experimental pieces like particle typography were iterated through prompt engineering until they degraded correctly under prefers-reduced-motion. The honest split: Kiro for scaffolding, boilerplate, and prototyping; me for the attendance math, the permission model, and the testing that proves the numbers are right.

ARCHITECTURE & TECH STACK

  • Frontend: Next.js 16 (App Router, server components and server actions), TypeScript, Tailwind CSS v4, custom dark-first design system with a four-level motion system (gated by prefers-reduced-motion)
  • Backend: PostgreSQL via Drizzle ORM, cookie sessions with scrypt password hashing, Zod-style input guards; role checks enforced in the app layer (src/lib/auth.ts, src/lib/actions/*)
  • Key modules: src/lib/attendance-engine (deterministic math, zero AI at runtime), src/components/motion/ (animation system)
  • Tests: node:test unit tests for the attendance engine, Playwright E2E at 360 / 768 / 1440 px including reduced motion
  • Built alongside Kiro AI IDE during the Kiro Build Challenge sprint

LINKS & DEMO

  • GitHub Repository: https://github.com/viv-techcode/Present-sir 
  • Working Demo : https://present-sir-mocha.vercel.app/
  • Local demo: npm install && npx drizzle-kit push && npx tsx src/db/seed.ts && npm run dev — CR: cr@present.sir / presentsir, Student: student@present.sir / presentsir, Join code: CSE5A1

TEAM / BUILDER DETAILS

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article