HQS Scheduler
A contract project made to simplify scheduling for 400+ employees worldwide
The Inspiration
A mid-sized company approached me with a contract to create a tailored scheduling solution. They faced a common dilemma: existing enterprise schedulers were feature-heavy and cost-prohibitive, while simpler options struggled to handle hundreds of employees per shift efficiently.
The Process
My approach involved close collaboration with the client, ensuring the final product aligned perfectly with their unique business requirements. The development process comprised several key components:
User Interface (UI)
I prioritized intuitive design by mapping out common user flows for various roles (managers, line workers, supervisors). This user-centric approach informed my UI decisions. I drew inspiration from Cal.com, a NextJS-based meeting scheduler, for its clean and efficient interface.
Scheduling Algorithm
The core scheduling functionality presented the greatest challenge. Like the Traveling Salesman or box packing problems, optimal employee scheduling is computationally complex (NP-hard). To address this, I implemented a constraint programming solution, balancing efficiency and practicality.
Additional Challenges
Two other significant hurdles I overcame are common pain points in similar applications:
- Timezone Management: Ensuring accurate scheduling across different time zones. Given this challenge, many date libraries had mechanisms to deal with this, however they often had plenty of open issues surrounding this topic. I ended up making helper functions using DayJS to handle the conversions from the database format to display/input formats, and aimed to test them as much as possible to avoid any mistakes.
- Authentication and Authorization: Implementing robust security measures while maintaining ease of use. I spent hours on OWasp learning about all the practices, and ended up deciding to go with Supabase to handle the authentication.
The result
At the end of the project, we were able to successfully schedule employees in one location. There will be a slow rollout, while any other bugs are squashed. We may choose to also develop an algorithm to allocate headcounts, but that is a challenge for another day.