A production-ready final year project that replaces manual attendance registers with time-limited QR code scanning. Teachers generate a QR code per lecture from their dashboard; students scan it within five minutes using their phone camera.
Python | Django | Django REST Framework | JWT Auth | SQLite3 | Flutter | Dart | Provider | fl_chart | mobile_scanner | qrcode | Pillow
Manual attendance registers are slow, easy to proxy, and produce data that nobody actually looks at. Attendify replaces that entire workflow with a QR code system that takes three seconds per lecture and generates real analytics you can act on. If you are looking for a final year project with source code that solves a real institutional problem, this is a strong pick.
The application has two roles: teacher and student. When a teacher creates a lecture, the backend generates a UUID token and encodes it into a QR code image. That image is displayed on the teacher's screen with a live five-minute countdown. Students open the app, tap the scan button, point their camera at the QR code, and attendance is recorded. Once the five minutes expire, the token is dead — no one can mark attendance retroactively, and no one can share the QR on WhatsApp to mark it from outside the room.
On the student side, the app shows per-subject attendance percentage, a weekly bar chart, a monthly trend graph, and a notification panel for updates from the teacher. On the teacher side, every lecture has a drilldown showing exactly which students were present. Subject-level analytics show total lectures conducted and average attendance across the batch.
Each lecture produces a unique UUID-backed QR code, returned from the Django API as a base64 PNG. The five-minute expiry is enforced server-side — the frontend timer is cosmetic. Duplicate scans return a 400 error, so a student cannot mark attendance twice for the same lecture even if they somehow get the token a second time.
Login returns a JWT access token and a refresh token alongside the user's role. The Flutter app reads the role on login and routes the user to either the student dashboard or the teacher dashboard. A student calling a teacher-only endpoint gets a 403. Token refresh happens automatically on 401 responses, so sessions stay alive without forcing re-login.
Students see their attendance percentage per subject displayed as a progress bar. The graph screen pulls weekly and monthly data from a dedicated endpoint and renders it using fl_chart — one of the better charting libraries in the Flutter ecosystem. Teachers get subject-level analytics: total lectures held, average attendance percentage, and a student list per lecture.
The app has an in-app notification panel with an unread badge count. Individual notifications can be marked read, or all notifications can be cleared in one tap. This is wired to a real Django notifications app with REST endpoints — not a mock.
JWT tokens are stored using flutter_secure_storage, which writes to the Android Keystore and iOS Keychain rather than SharedPreferences. This is the correct approach for auth tokens and it is already set up in this project.
The backend is a Django 4.2 project with four internal apps: users, lectures, attendance, and notifications. Django REST Framework handles serialization and views. Authentication is JWT via djangorestframework-simplejwt. The database is SQLite3, so there is no database server to configure — just run migrations and go.
The Flutter frontend uses Provider for state management. API calls go through Dio, which is configured with an interceptor that catches 401 responses and attempts a token refresh before retrying the original request. Camera access for QR scanning uses the mobile_scanner package.
The project ships with a seed data management command that creates one teacher account, five student accounts, three subjects, ten lectures, and randomised attendance records. You can be logged in and exploring the full app within ten minutes of cloning the repo.
The obvious use case is a college attendance system, but the underlying architecture applies to any scenario where you need time-gated, one-time-use token validation with role-based dashboards. The same pattern works for workshop check-ins, event registrations, library access tracking, and corporate training sessions. If you are planning to extend this as a Python final year project, the backend structure is clean enough to add new apps without touching existing code.
You get the complete Django backend source code, the complete Flutter app source code, a pre-built project report formatted to standard college submission requirements, and setup documentation. The report covers abstract, system architecture, ER diagrams, use case diagrams, API documentation, and future scope — everything your evaluation panel will look for.
If you need additional help, CodeAj offers project setup sessions with source code explanation, custom report writing, research paper preparation, and PPT creation as add-on services.
This project works well for BCA, MCA, BTech CSE, and BSc IT students in their final year who need a full-stack mobile project with a working backend. The tech stack — Django and Flutter — is in demand at the fresher hiring level, so the project does double duty: it clears your submission and gives you something real to explain in an interview.
If you want a project that goes beyond a basic CRUD app, uses JWT authentication correctly, handles real-time concerns like token expiry, and produces charts from actual data, Attendify covers all of that. Browse more AI and Python final year projects with source code on the CodeAj marketplace to compare options before you decide.
Add any of these professional upgrades to save time and impress your evaluators.
We'll install and configure the project on your PC via remote session (Google Meet, Zoom, or AnyDesk).
1-hour live session to explain logic, flow, database design, and key features.
Want to know exactly how the setup works? Review our detailed step-by-step process before scheduling your session.
Fully customized to match your college format, guidelines, and submission standards.
Need feature changes, UI updates, or new features added?
Charges vary based on complexity.
We'll review your request and provide a clear quote before starting work.