ShiftrApp

Turning a single bar's scheduling chaos into a multi-tenant operations platform for hospitality teams.

Role
Product Designer & Systems Architect
Time
2026 — ongoing
Platform
Multi-tenant web app + PWA (RTL)
Domain
Workforce Operations / Hospitality
ShiftrApp scheduling screens on desktop and phone

01 – Background & Challenge

The Problem

Shiftr started as a fix for one bar I worked at: schedules built in Excel, published as WhatsApp screenshots, and patched together in chat threads until nobody was sure who was actually working. The moment a second venue asked to use it, the problem changed shape — this was never a scheduling calendar, it was an operations platform that had to hold many independent businesses without ever letting one venue see another's data.

  • Managers don't need a calendar, they need a decision aid that holds availability, role eligibility and last-minute changes
  • Floor staff use the product standing up, one-handed, in a loud room, for ninety seconds at a time
  • Every venue thinks its rules are unique: role names, shift patterns and deadlines differed at every bar

02 – Core Product Strategy

Key Decisions

1Organisation as the Core Unit of the Product

Problem

The first version assumed one venue. Adding a second exposed that staff, roles, shifts and settings all had no owner — and that any leak between businesses would be fatal to trust.

Decision

Rebuilt the product around an organisation entity: every user belongs to one or more organisations, an explicit org-selection step sets context, and all data access is scoped at the database layer.

Reasoning

Tenancy is a structural property, not a filter. Enforcing it beneath the UI means no future screen can accidentally expose another venue's roster.

Impact

Shiftr became a platform rather than a tool: new venues onboard independently, and multi-venue staff switch context in a single tap.

Organisation as the Core Unit of the Product screen

2Invite-Based Onboarding Instead of Open Sign-Up

Problem

Anyone could create an account and land nowhere — no venue, no role, no context — while managers had no reliable way to get their actual team into the system.

Decision

Designed a tokenised invite flow: the link survives the whole sign-in or sign-up journey, and the new member lands inside the right organisation with the right role attached.

Reasoning

In workforce software, membership is granted by the business, not claimed by the user. Preserving the invite removes the most common drop-off point.

Impact

Team setup collapsed into one link, and no user ever reaches an empty, contextless state.

Invite-Based Onboarding Instead of Open Sign-Up screen

3Venue-Defined Roles and a Separate Permission Layer

Problem

Hard-coded roles like 'Bartender' broke immediately, and tying job title to system capability meant scheduling rights also changed who could work which shift.

Decision

Split the model in two: venues define their own roles for scheduling eligibility, while a separate permissions surface controls what each member can do in the system.

Reasoning

'What you're qualified to work' and 'what you're allowed to change' are different questions. Separating them avoids over-granting access.

Impact

Every venue models its own team accurately, and permission changes became a deliberate, auditable act.

Venue-Defined Roles and a Separate Permission Layer screen

03 – Results & Value

Outcomes & Impact

Multi-venue

Independent organisations, fully isolated

1 link

Invite-based team onboarding

0 chasing

Automated availability reminders

The coordination work that used to live in a manager's head and a group chat now lives in the product. Venues onboard themselves, staff handle their own availability and swaps, and managers step in only where judgement is genuinely required.

04 – Reflection

Lessons Learned

Designing a multi-tenant product taught me that flexibility and opinion aren't opposites — they're a sequencing problem. Every venue's rules were unique, but only at the edges; underneath, the workflow was the same. I also learned how much of operational software is really permission design: who can change what is a product decision with real consequences.

TNDTom Nizan – Product Designer