Building an attendance ERP that answers "how many classes can I miss?"

Our college attendance portal does not show an attendance percentage or help students understand the effect of taking leave. After talking it through with my Class Representative, I built an attendance system around the questions students actually ask:

• If I take leave tomorrow, what will my attendance become?
• How many more classes can I safely miss before dropping below 80%?
• If I am below the required percentage, how many classes do I need to attend to recover?
• Who is consistently bunking in between classes?

The first version has multi-department and multi-section support, student and staff management, and a multi-semester design with semester archiving. On the analytics side it predicts attendance after future absences, includes a safe-bunk calculator and recovery planner, detects mid-class bunking and tracks late arrivals. Subject-wise and overall analytics feed an admin dashboard with filters and reports, an academic calendar covers holidays, exams and events, and attendance audit logs plus role-based access control keep records accountable.

The data model handles multi-hour labs that are marked once, partial exam days and one-off period swaps, because real timetables are messier than one class per hour. Marking is mobile-first, and a timetable builder checks for conflicts.

The app runs on Cloudflare Workers with a D1 database, using Next.js, Hono, Prisma and TypeScript. From identifying the problem to a working MVP took less than a day. It is a first version, and I am improving it from user feedback.

• A 2-hour lab is one class the faculty marks once, but it costs the student 2 hours of attendance.
• An exam can take hours 1–2 while hours 3–7 run normal classes.
• Mentor-mentee meetings are compulsory but should not lower an academic percentage.
• A student who skipped hour 4 and returned for hour 5 bunked; one who never came was absent. Those are different problems.

The system models each of these explicitly instead of approximating them.

A bunk is a present-to-absent change within a single day: attended hour 3, missed hour 4. One missed period is flagged as a single-hour skip, and two or more in a row as a mid-class bunk. A student absent all day is simply absent.

A nightly job recalculates health scores, detects bunk patterns and raises alerts at warning and critical thresholds. Admins get a daily bunkers list, a heatmap of attendance by weekday and period, a bunk leaderboard and late-arrival analytics.

Crossing dates are not extrapolated from a formula. The planner walks the actual future timetable of your section day by day, skipping holidays and non-working days, and reports the exact date your percentage first drops below the target if you keep skipping, or climbs back if you attend everything. A what-if simulator lets students test a number of absences or specific dates.

Present-like statuses are present, late, very late, medical and on duty. Subjects such as mentor meetings still record attendance but are excluded from every percentage.

• Days can be locked so records become immutable.
• Every edit needs a reason, written to an append-only audit log.
• Five roles, from super admin to student, each see only what they should.
• Student CSV import validates every row and writes nothing if any row fails.
• Excel and CSV exports stream on request, with no file storage needed.

The API is Hono and the front end Next.js 15 with Tailwind, both on Cloudflare Workers, with TanStack Query for data and Zod validating every request. The schema has 20 models. It was first designed for PostgreSQL with nine native enums, but D1 is SQLite, which has none, so those became text columns exported as TypeScript string unions. D1 also has no interactive transactions, so writes use batched arrays and nested writes instead.