Building iAttend: A Full-Stack Attendance & Leave Management System

Academic Milestone: iAttend was designed and built as a final-year academic project—a full-stack system built to replace manual paper registers, synchronize medical leave approvals directly with attendance records, and give students and parents real-time visibility.

In most colleges, taking attendance is still surprisingly manual. Teachers carry around paper registers, spend five to ten minutes of every lecture calling out roll numbers, and manually tally totals at the end of each month. Students usually have no clue whether their attendance is dipping below the mandatory 75% threshold until exam hall tickets are held back. And if you fall sick and need to submit a medical leave, you spend days chasing teachers, class coordinators, and the HOD for physical signatures.

For our final-year engineering project, I led a team to build a practical, production-ready solution that directly addressed this everyday campus headache instead of building another generic clone.

As Team Leader and Backend & Database Developer, I designed the core architecture, REST APIs, and database schemas, working alongside my teammates to take the project from initial idea to a deployed web platform.

Project Team & Roles

Building a platform that connects five distinct user roles required dedicated collaboration across design, engineering, and testing:

• Md Yusuf — Team Leader | Backend & Database Developer
• Jubair Ahmad Siddiqui — Frontend Developer
• Mishkat Mariyam — Testing
• Manahil Farooq & Mishbah Shahab — UI/UX & Graphics

The Core Problems I Wanted to Solve

When analyzing how attendance and leave tracking works in colleges, three recurring friction points stood out:

1. Disconnected Leave and Attendance Records: When a student takes an approved medical leave, the approval usually stays on a paper slip. When teachers mark attendance during lectures, the student is marked absent. Weeks later, someone has to manually reconcile the approved leaves with the daily registers, which almost always leads to mistakes.
2. Lack of Early Visibility for Students and Parents: Students usually find out about attendance shortages at the end of the semester when it is too late to fix. Parents are kept completely out of the loop unless a warning letter is mailed home.
3. Slow, Fragmented Administration: Setting up classes, assigning subject teachers, and updating timetables often involves separate spreadsheets that quickly get out of sync.

My goal with iAttend was to create a centralized system where marking attendance takes less than thirty seconds, leave approvals automatically reflect in attendance logs, and students and parents can check real-time attendance from any device.

System Roles & Permissions

A college has a clear hierarchy, so a flat user model would never work. I designed five separate roles, each with its own dedicated dashboard and access permissions:

• Admin: Manages master data. The admin creates academic departments, assigns classes and subjects, manages user accounts, and maintains semester schedules.
• Teacher: Assigned to specific subjects for specific classes. A teacher can mark lecture attendance, view historical session logs, and approve or reject subject-specific leave requests.
• Class Coordinator: A designated faculty member responsible for an entire class. Coordinators review formal leave requests (such as medical leaves), inspect attached proof, and make final decisions that affect overall attendance records.
• Student: Can view their subject-wise attendance percentages, inspect their class timetable, and submit leave applications with document attachments.
• Parent: Can log in using dedicated parent credentials linked to their child's account to monitor daily attendance trends, subject percentages, and leave status.

Architecture & Tech Stack

iAttend has three main parts: the screens people use, the server that applies the rules, and the services that store the data. I used the MERN stack—MongoDB, Express, React, and Node.js—so the interface and server could both use JavaScript.

Example: When a student opens their attendance dashboard, React requests the records, Express checks their access, and MongoDB returns the data. The student sees the result on screen.

Built for Classroom Use

• Phone-friendly screens: Teachers can mark attendance from a smartphone while standing in a classroom.
• Small, helpful animations: Slide-over panels, modals, and status changes use Framer Motion to make interactions easier to follow.
• Cloud deployment: The backend runs in a Docker container on Render. The frontend is deployed as a static site.

How Attendance & Leave Sync Works Under the Hood

The most important engineering challenge in iAttend was making sure attendance records and leave requests were not treated as isolated silos.

1. Daily Attendance Marking

When a teacher selects a class and subject, the frontend fetches the active student roster. By default, all students are initialized as "Present." The teacher only needs to tap the students who are absent, which keeps marking under thirty seconds.

When the attendance form is submitted:

1. The backend validates that the requesting user is authorized to mark attendance for that specific subject and class.
2. An attendance session document is created with date, subject ID, teacher ID, and an array of student statuses (Present, Absent, or On Leave).
3. If an unexcused absence is recorded, an automated email alert can be sent to the parent's registered email address.

2. From Leave Request to Updated Attendance

A leave request only changes attendance after it is approved. Here is the process from the student's point of view:

Example: A student is marked absent on Monday and Tuesday. If medical leave for those dates is approved, the matching records become On Leave. Staff no longer need to correct each record manually.

Real Problems I Ran Into & How I Fixed Them

Building a multi-role system from scratch surfaced several practical issues that tutorial projects never talk about.

1. Docker Container Permissions on Render

When I first containerized the backend and deployed it to Render, file uploads kept crashing with EACCES: permission denied errors.

Because containers on Render run with specific user permissions and ephemeral filesystems, the temporary directory used by multer for processing uploaded certificates before pushing to Cloudinary lacked write permissions in certain container execution states.

Instead of writing temporary files to the local container disk and then uploading, I refactored the upload pipeline to process incoming files directly in memory via multer.memoryStorage(). The buffer is streamed straight to Cloudinary's API. This eliminated local file write locks entirely and made the server stateless.

2. Timezone Glitches in Daily Attendance

One of the most frustrating bugs during early testing was attendance dates shifting by a day. A teacher would mark attendance on Friday afternoon, and on Saturday morning the dashboard would display it as Thursday evening.

This happened because date objects were stored as UTC timestamps in MongoDB, and depending on whether the server was running on my local machine or on a cloud server in a different region, new Date() formatted dates differently.

I fixed this by standardizing attendance dates to YYYY-MM-DD string keys at midnight UTC in the database, while formatting localized display times on the client side based on the browser's timezone.

3. Preventing Duplicate Attendance Entries

The problem: A teacher could tap “Submit Attendance” twice while waiting for a response. Without a database check, both requests could create the same attendance record.

The rule: In this data model, a class + subject + date combination must be unique. MongoDB enforces that rule with a compound unique index: a check across all three fields together.

A simple example: Class BCA-3 submits attendance for Networking on 18 September. Submitting the same class, subject, and date again is a duplicate. A different subject or date creates a different combination.

Here is the database rule. The field names in this schema are class, subject, and date:

attendanceSchema.index(
  {
    class: 1,
    subject: 1,
    date: 1,
  },
  { unique: true }
);

• The three fields define the combination MongoDB checks. The 1 values specify ascending index order.
• unique: true prevents a second record with that same combination.
• If a duplicate arrives, the backend catches the database error and shows a clear message instead of saving another record.

Result: An accidental second submission does not duplicate the attendance data. This particular rule allows one record per class, subject, and day; supporting multiple sessions for the same subject on the same day would require a session identifier in the uniqueness rule.

Security & Data Integrity

Given that academic records and medical documents are sensitive, I implemented several foundational safeguards:

• Password Hashing: All passwords are encrypted with bcrypt before saving to MongoDB.
• Role-Based JWT Middleware: Every protected route passes through a token verification middleware followed by a role check middleware (e.g., verifyRole(['Admin', 'Coordinator'])). This prevents students from manipulating request bodies to approve their own leaves or modify attendance percentages.
• Sanitized Inputs: MongoDB queries use Mongoose validation schemas to guard against NoSQL query injection.

What I Learned from This Project

Building iAttend as my final-year project taught me a lot about full-stack engineering beyond writing simple CRUD endpoints:

1. Role-Based Access Control (RBAC): Designing distinct permission levels for five different user roles required thinking through authentication flows, route guards, and UI conditional rendering systematically.
2. Business Logic Synchronization: Connecting leave approvals directly to attendance status showed me how real business rules depend on cross-collection consistency.
3. Stateless Cloud Architecture: Moving from local file storage to cloud storage with Cloudinary reinforced why containerized web services must remain stateless.
4. Mobile Usability Matters: A desktop-first design doesn't work for teachers in classrooms. Prioritizing touch targets and mobile-responsive layouts made the tool practical in real-world environments.

Try the Live Demo

The project is deployed and live. You can explore the student view without signing up:

• Live URL: https://iattend.online
• Role: Student
• Demo Email: stud1@gmail.com
• Demo Password: stud123

(Please note: This is a shared read-only demo account, so please do not submit test spam or alter account details.)

Related Project

• Live Application: iAttend Web App
• Source Code: The repository is not currently publicly accessible.