RoostyStaff scheduling for hospitality venues, live at app.roosty.nl

One spreadsheet, three venues, and a manager who was the only person who knew why the roster worked.

• A spreadsheet roster maintained by hand, week after week
• Overlapping shifts and closed days caught by eye, or not
• Overnight hours miscounted because the sheet did not know about midnight
• Every change meant re-checking the whole week

This is our own account of the before state. It describes a manual workflow, so it is the one thing on this page the repository cannot check.

A board that thinks in shifts, hours and rules, and knows which of them can be overruled.

Roosty is a Next.js app on a multi-tenant Supabase backend with row-level security, so each organisation only ever sees its own data. The week board shows every venue with its own opening hours; shifts are dragged between days and venues and paid hours recompute from one time library that understands midnight. Seven conflict rules re-run over the whole week on every change: three surface as warnings the planner can publish anyway, four (an overlap, two venues at once, a closed day, no responsible role on duty) have to be resolved first. Suggestions for open shifts are ranked deterministically and come with their reasons. Publishing freezes the week as a snapshot; employees are invited from the app and see their shifts the moment the week goes out.

One board instead of a spreadsheet.
The judgement stayed with the planner.

• A weekly board per venue, with opening hours and closed days built in
• Conflicts surface instantly: three soft ones can be published anyway, four hard ones have to be resolved first
• Contract hours versus scheduled hours per employee, per week
• A multi-tenant backend with invites, so a team is onboarded from the app