More project photos (3)
The problem
In many housing societies, covered parking slots are fewer than families, so slots rotate: each wing gets the covered bays for a quarter, then they pass on. The rotation schedule usually lives in a committee member's spreadsheet, residents don't know their next slot until someone tells them, and informal swaps happen over chat with no record. Disputes follow — not from bad intent, but from invisible process. A rotation manager makes the system legible: a visual slot map of who holds what, published quarterly rotation cycles, and a consent-based swap workflow. When every resident can see the schedule and the rules, the committee stops re-explaining the cycle every meeting.
Views the slot map, requests swaps and previews the next rotation cycle.
Follow the working sequence
How it works
- The 24-slot dataset is seeded with holders across wings A, B and C, EV-charging flags and visitor-pool bays.
- The slot map renders the grid from this data, highlighting the resident's slot (P-07) and marking special bays.
- The rotation table publishes four quarterly cycles with wing-wise allocations; the rules explainer sits alongside.
- A resident opens the swap modal, picks a desired slot and records a reason; the request appears on the board as Pending.
- The other holder accepts or declines; the request's state updates with feedback, and approved swaps are recorded.
- The next-cycle preview action shows the resident's upcoming allocation from the published cycle.
- All views — map, cycles, swaps — re-render from the single store on every change.
Tech stack:
- HTML5, CSS3, JavaScript (ES6)
- Single-file app — runs fully offline
- Grid-based spatial slot map
- Request/approval workflow state machine
- Single-store state management
| Parameter | Value |
|---|---|
| Application type | Society resource-management portal |
| Demo delivery | Single HTML file, runs offline in any modern browser |
| Slot count | 24 (incl. 2 EV-charging bays, visitor pool) |
| Rotation cycles | 4 quarterly cycles with wing allocations |
| Swap states | 2 (Pending / Approved) with accept-decline actions |
| Rotation period | Quarterly (design context) |
| Seeded demo | 16 named holders across 3 wings |
Project features
- [Visual 24-slot map] Every bay with its holder, the resident's own slot highlighted, EV-charging bays and the visitor pool marked.
- [Quarterly rotation cycles] Cycle table with periods, wing-wise slot allocations and statuses (current, published, draft).
- [Rotation rules explainer] The five rules of the rotation written plainly next to the schedule — no folklore needed.
- [Consent-based swaps] Request a swap with a reason; holders accept or decline; approved swaps recorded with both parties named.
- [Next-cycle preview] One click shows the resident's slot in the upcoming quarter — no surprises on rotation day.
- [Swap request board] Pending and approved requests with from/to slots, requesters and reasons — the audit trail.
- [Realistic society data] Holders across three wings, four quarterly cycles and mixed-state swap requests seeded for demo.
What is included
- Working parking slot rotation manager web app
- Complete source code with comments
- Project report PDF (background, fairness problem, rotation design, screens)
- PPT presentation for final review
- Viva Q&A preparation document (web concepts, workflow design, state management)
Limitations & prerequisites
- The demo keeps data in memory; a production version needs a backend so the schedule and swaps are shared across residents.
- Swaps are bilateral in the demo; committee approval for contested swaps is future scope.
- Rotation cycles are published data, not auto-computed from seniority rules (auto-computation is future scope).
- No notifications — residents aren't alerted to upcoming cycle changes or swap decisions.
- No physical enforcement; the system records allocation, it doesn't detect who's actually parked.
- Single society assumed; multi-society or multi-tower support is out of scope.
Frequently Asked Questions
How does the rotation stay fair?
The published cycles show exactly which wing holds which slots each quarter, and the rules (wing order, seniority priority, EV-bay handling) are visible next to the schedule — fairness through transparency.
What if two residents want the same slot?
Swaps need the holder's consent — accept or decline with the reason recorded on the board. Contested cases escalate to the committee, which is the documented future-scope workflow.
Do EV-charging bays rotate too?
Yes, but on their own track — the demo marks P-23 and P-24 separately and the rules call this out explicitly.
What happens on rotation day?
The next published cycle becomes current; the preview action lets every resident see their upcoming slot in advance so nobody is surprised.
Can visitors use the free pool?
The map marks visitor-pool bays; booking them against the pool is designed and listed as future scope.
Is this project suitable for a final-year project?
Yes — for Computer Science, IT and Web Development programs. It demonstrates workflow design, spatial UI and a fairness problem solved with transparency. 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
- Grid-based spatial slot map
- Request/approval workflow state machine
- Single-store state management
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.
Download free synopsis (PDF)
Enter your name and WhatsApp number — the synopsis PDF downloads immediately. We may send occasional project updates on WhatsApp; no spam.