AppsCase studyShift app
A swap that both sides can watch.
A concept for shift scheduling in cafés and restaurants: a phone app for the staff and a rota builder for the manager, built as one coded prototype so you can see each side react to the other.



- Type
- Concept, self-initiated
- Role
- Design and build
- Scope
- Staff app and rota builder
- Built with
- React, TypeScript, Motion
The challenge
I used to work as a barista, and the café I worked at planned its rota the way a lot of small places do: in a spreadsheet, with a screenshot of it sent to the team. Shifts in a café change all the time, because someone is ill, someone has an exam or a delivery moves to the morning, so a single swap turned into a thread of messages, a manager checking the rest hours by hand and a new screenshot that was easy to miss. Tura started from that.
I wanted to design the whole loop rather than one screen of it: the person who can’t make a shift, the colleague who covers it, and the manager who approves it without breaking the rules on rest time or contract hours. A tool like this only works if both sides trust what they see, so the part I cared about most was the moment where the two meet.
My role
Tura is my own project, so I did all of it: the brand kit and the two key screens in Figma (the staff app’s My shifts and the manager’s rota builder), the remaining screens directly in code from the same kit, and the prototype itself in React and TypeScript. What you can try here is only the prototype: there is no backend yet, so everything runs in the browser on an invented café, Café Molotov in Cluj-Napoca, with six people and two weeks of shifts. The real app, with a backend behind it, is in the works.
Key decisions
- The rules are checked before the manager decides, not after. Every request reaches the inbox with the check already done: eleven hours of rest kept, nobody booked twice, contract hours respected and what it does to the labour cost. Bianca still makes the call, but she no longer has to do the arithmetic.
- A conflict comes with a fix. The rota marks a rest-time conflict in red, and its popover offers one concrete way out rather than a warning. My first idea was to swap the shift with another colleague, but that still left him with only nine hours of rest, so the fix moves him onto the open late shift instead, which keeps his hours the same and gives him seventeen hours off.
- Asking for cover starts with who can actually cover. When Ana can’t make a shift, the app suggests colleagues who are free that day, work the same role and stay within their contract, and says why for each one. Offering it to the whole team is still there for when nobody fits.
- Motion only where it explains something. Most of the interface is quiet. The one place it is allowed to be bold is Auto-fill, where next week’s rota fills in day by day, because that is the moment the tool saves the manager an evening. Anything started from the keyboard happens instantly.
Try it: one shift, both sides

What to try
- On Ana’s phone, give away Thursday’s closing shift and ask Mihai to cover it.
- As Bianca, approve the swap and watch the shift move to Mihai on the rota.
- Plan week 47 with Auto-fill, then publish it to the team.
Interactive prototype · mock data
On a small screen you get Ana’s phone; the rota builder joins it on a wider one.
Outcome
The real app isn’t out yet, so there are no users or numbers to report. What the prototype does show is the full swap from both sides: Ana gives away her Thursday, Mihai says yes, Bianca approves with the rules already checked, the shift moves on the rota and Ana’s phone confirms it.
Building it in code rather than as linked Figma frames meant that every number on screen is calculated from the same data, so the labour cost, the hours and the conflicts always agree with each other, which a static prototype can’t promise. It also made me design the states a Figma flow usually skips, such as a request that arrives while the manager is on another screen.
What I’d do next
The next step is the real app, which is in the works. Alongside it, the obvious gap is real people: I would put the staff app in front of a few café and restaurant teams to see whether the cover suggestions match how they actually decide who to ask, because in a small team that is often about who owes whom a favour, which no rule captures.
On the manager’s side, Auto-fill builds the week from availability and contract hours alone; it should also learn from the changes the manager makes by hand afterwards. I would also add timesheets, which I left out of the prototype on purpose, so that nothing on screen is a button that doesn’t work.