Problem
Small businesses often coordinate rosters across spreadsheets, screenshots and messaging. That makes schedule versions, availability, leave and shift changes difficult to control.
Interactive visual stories
Explore the scheduling experience
An interactive, illustrative walkthrough of shift planning, manager decisions and request workflows. No real staff data is shown.
Concept visuals · no client screenshots
Illustrative project visuals are available with JavaScript enabled. The case study below remains fully accessible.
My role
I framed the business problem, translated it into workflows and data relationships, and implemented the prototype across manager and staff experiences.
What I worked on
Manager scheduling
Create weekly schedule records, add shifts, enforce submitted availability, and move schedules between draft and published states.
Staff experience
View published shifts, total weekly hours and day-by-day assignments through a separate staff workflow.
Request workflow
Staff can submit leave or swap requests; managers can review, filter, approve or reject them with shift context.
Proof of work
Verified stackNext.js 16.2.2, React 19.2.4, TypeScript, Tailwind CSS 4, Supabase JS and PostgreSQL-backed data access.
Schedule logicThe manager schedule code uses schedule_weeks and scheduled_shifts, validates dates within the selected week and checks submitted availability before inserting a shift.
Publish controlSchedule status is explicitly stored as draft or published, with publish/unpublish handling and published_at updates.
Request handlingLeave and swap requests use pending / approved / rejected states and manager review timestamps.
Role flowsSeparate manager and staff routes exist for schedule, requests and availability.
Tools & capabilities
Business AnalysisWorkflow DesignNext.jsReactTypeScriptTailwind CSSSupabasePostgreSQLGit/GitHub
What this demonstrates
This project shows that I can move from an operational problem to requirements, system logic, relational data and a working interface — and explain the decisions in business terms.
Authentication is currently a prototype session model stored locally in the browser. Supabase is used for application data; production-grade authentication and access control are a future hardening step. I state this explicitly so the case study reflects the repository accurately.
Next step