Case Study 01

Bar Rota

A weekly scheduling system for a venue with five spaces and a staff roster that never stopped moving - designed, built, and shipped solo.

RoleSole builder - product, design & engineering
StackSupabase (Postgres, Auth, RLS), HTML/CSS/JS, Netlify
UsersBar staff and managers, live weekly use
TimeframeOngoing
Problem

Rotas were living in someone's head.

The venue runs multiple spaces that don't all operate every day - a main bar that's always open, plus a second bar, an events space, a pop-up, and kitchen support that come and go depending on what's booked in. Staff availability shifted week to week, and getting a fair, accurate schedule out meant a manager manually cross-referencing who could work where, every single week.

There was no single source of truth. If the person who usually built the rota was off, nobody else could confidently reconstruct it.

Decisions

What I chose, and what I gave up

bar-rota/decisions.log4 entries
decidedmodel the week as Saturday→Friday, matching how the venue actually thinks about its trading week - not the calendar week
decidedmake secondary venues (Wee Bar, Mandela, Pop-up, Kitchen Porter) toggle on/off per day instead of hard-coding a fixed set of spaces
shippedseparate manager and staff views - staff submit availability, managers publish the rota, swaps sit in their own approval flow
learnedrow-level security in Supabase does the access-control work I'd otherwise have hand-rolled in the backend
User journey

From availability to a published shift

  • Staff log in and submit their availability for the coming trading week
  • Managers see availability against the venues actually open that week and build the rota
  • Staff view their own shifts and can request swaps with colleagues
  • Swap requests go through a lightweight approval flow rather than being silently accepted
Screenshot: weekly rota view (manager.html)
- drop in a real screenshot here
Architecture

Kept deliberately simple

No framework, no build step - plain HTML, CSS, and JS talking directly to Supabase for auth, data, and row-level security. Pages: login, availability submission, personal shift view, swap requests, and two manager-only views for scheduling and staff management. The simplicity was a decision, not a limitation: it meant I could ship changes the same day a manager asked for them, without a deploy pipeline in the way.

Diagram: page map / data flow between login → availability → manager → swaps
- drop in a real diagram here
Reflection

What I'd do differently

Building this solo, end to end, taught me how much of "product work" is actually just talking to the one manager who has to use this thing every single week and noticing when their answer to "does this work for you?" is polite rather than true.

If I rebuilt it now, I'd instrument it from day one - right now I know it's used, but I don't have the data to say how it changed the manager's actual time spent building a rota. That's the gap between "shipped" and "measured," and it's the one I'm most conscious of closing on the next project.