The problem
Apartment gate security runs on phone calls: a visitor arrives, the guard calls the flat, the resident — often in a meeting — doesn't pick up, and the visitor waits while the queue builds. Pre-approval flips this: the resident registers expected visitors in advance, the gate receives a pass code, and entry becomes a code check instead of a phone chase. This project builds the resident side of that loop as a web portal — pre-approve guests with purpose, date, time and vehicle details, generate instant 6-digit gate passes, watch the live visitor board, and review a 7-day history. No hardware, no guard-side app needed for the resident workflow to demonstrate its value.
How it works
- The resident fills the pre-approval form: name, phone, purpose, date, expected time and optional vehicle number.
- Submitting generates a unique 6-digit gate pass and renders it as a formatted pass card with flat A-1204 context.
- Share buttons send the code to the visitor over WhatsApp or SMS (simulated with confirmation in the demo).
- The visitor is appended to today's list with an "Expected" pill; dashboard counts update.
- The gate verifies the code against the live board instead of calling the flat — the status moves to "Inside now" on entry.
- Checkout updates the status again; the visit lands in the 7-day history with in/out times.
- Passes are date-bound — a code is valid for its selected date only.
Tech stack:
- HTML5, CSS3, JavaScript (ES6)
- Single-file app — runs fully offline
- Client-side pass-code generation
- Status-lifecycle state machine
- Share-action UI patterns
| Parameter | Value |
|---|---|
| Application type | Resident visitor-management portal |
| Demo delivery | Single HTML file, runs offline in any modern browser |
| Pass format | 6-digit numeric code, unique per visitor (design target) |
| Pass validity | Selected date only (design behavior) |
| Visitor statuses | 3 (Expected / Inside now / Checked out) |
| History window | 7 days |
| Seeded demo | 5 live visitors + 7-day history log |
Project features
- [Pre-approval form] Visitor name, phone, purpose, date, expected time and optional vehicle number — one form covers every gate question.
- [Instant 6-digit gate passes] Unique code per approval rendered as a formatted gate-pass card with flat, purpose and validity context.
- [Live today's-visitors board] Expected, checked-in, awaiting and checked-out counts with per-visitor rows, codes and status pills.
- [Pass sharing] One-tap WhatsApp and SMS share actions so the code reaches the visitor before they travel.
- [7-day visitor history] Every past entry with purpose, date and in/out times — the society's paper register, digitized.
- [Status lifecycle] Expected → Inside now → Checked out, color-coded so the gate's state is readable at a glance.
- [Pre-seeded realistic data] Five visitors across all statuses plus a full week of history, so every screen demos immediately.
What is included
- Working visitor pre-approval portal web app
- Complete source code with comments
- Project report PDF (background, gate-management problem, pass design, screens)
- PPT presentation for final review
- Viva Q&A preparation document (web concepts, token design, state lifecycle)
Limitations & prerequisites
- Pass codes are generated client-side in the demo; a production system needs server-issued, single-use codes with expiry enforcement.
- No guard-side verification app — the demo shows the resident workflow; guard check-in is simulated.
- Share actions simulate delivery; real WhatsApp/SMS integration needs API credentials.
- No photo capture or ID verification at the gate in this build.
- Single flat assumed; multi-flat or family-member roles are out of scope.
- The demo's "Inside now" transitions are manual; sensor-based auto-detection is future scope.
Frequently Asked Questions
How does the gate verify a visitor?
The guard matches the visitor's 6-digit code against the live expected-visitors board — no phone call to the flat needed. The demo renders the same board the guard would see.
Can't someone guess a pass code?
Six digits over a single date with a short visitor list is a demo-grade scheme; the report documents the production hardening — server issuance, one-time use, expiry and rate-limited verification.
What about delivery partners?
They're first-class visitors: purpose "Delivery" with the order context in notes, same pass flow, and typically in-and-out within minutes.
Do recurring visitors need a pass every day?
In the demo, yes. Recurring approvals (daily househelp, weekly vendors) are designed and listed as future scope.
Can the society see all flats' visitors?
The demo is the resident view for one flat; a committee dashboard aggregating across flats is a natural extension noted in the report.
Is this project suitable for a final-year project?
Yes — for Computer Science, IT and Web Development programs. It demonstrates token-based verification design, state lifecycles and a genuinely useful society tool. Suitable for B.E./B.Tech final-year projects in Computer Science, IT and Web Development.
Components & software requirements
- HTML5, CSS3, JavaScript (ES6)
- Single-file app — runs fully offline
- Client-side pass-code generation
- Status-lifecycle state machine
- Share-action UI patterns
Delivery information
Built-to-order project. Delivery timeline is shared after order confirmation based on current queue.
Support terms
Complete documentation, setup guide, and viva preparation included. Support for setup and explanation provided.