Staff Management Dashboard
An internal company platform built as two linked web applications, one for people, scheduling, and requests, and the other for tasks, payments, cloud storage, and events, unified under a single role-based access model. One codebase, two product surfaces, designed so a company can run its whole back office in one place.
Developer
2026
This website is a full internal operations suite for a company that manages a roster of people and the work, money, and scheduling that flows between them. It's split into two linked sites that share an account system and a permission model. First one handles the human side: user management, per-person availability, booking requests between connected users, a personal calendar, and an action log. Second one handles the operational side: task assignment and collaboration, one-off and recurring payments with spend analytics, two separate cloud-storage products (a media gallery and a general file store), and a full events system.
The backbone is a four-role access graph. Admin, Parent, Model, and Guest, where users never see the full directory, only the people they are explicitly connected to, enforced on the server rather than hidden in the UI. The most distinctive part is a delegation system: a custom access middleware lets a Parent act on behalf of a connected Model. It verifies the parent-child relationship, then rewrites the request's identity to the child's, so a parent can book time or assign tasks directly while a model retains the ability to formally request detachment from that link. Scheduling is modeled as a weekly availability template layered with dated overrides, each timeslot carrying a colored tag; slots tagged "Free" become bookable by connected users through an accept/reject request flow, and the personal calendar merges a user's own slots with any accepted requests where they're either side of the booking. A per-user setting even controls whether the two sites are presented as one combined experience or kept separate.
Designing the delegated-access pattern: verifying a parent-child link and safely rewriting request identity to act on a connected user's behalf, without opening a path to act on users you aren't linked to.
Connection-scoped visibility. Every list, request, and lookup had to be filtered server-side to the set of users you're connected to, never the global directory.
Modeling availability as a weekly template plus dated exceptions with tagged slots, then merging templates, overrides, and accepted bookings into one coherent calendar view.
Role-based approval flows with deliberate bypasses (a parent assigning a task directly to a connected model skips the normal accept step) without making the permission logic unreadable.
Unifying two functionally distinct products under one auth and permission layer while letting each user choose to combine or separate them.