shift management platform · flutter, firestore, hive
Shiftly
A shift-management app for teams whose rota changes faster than a spreadsheet can be re-sent.
Overview
Rotas move; spreadsheets do not
One schedule everybody actually sees
Shiftly keeps shifts, swaps and availability in a single Firestore-backed schedule, with Hive caching locally so the roster is readable the moment the app opens — and still readable when the signal drops mid-shift.
The problem
A rota is not usually wrong — the version someone is looking at is. Re-sending a spreadsheet creates another version rather than replacing the last one, and shop-floor connectivity is exactly where a cloud-only app stops working.
The goal
Keep one shared schedule that propagates changes instead of re-announcing them, and stays readable when the signal drops mid-shift.
How it was built
- 01Discovery
Watching where the schedule breaks down
The failure is rarely the rota itself — it is the version of it someone is looking at. That pointed the product at a single shared source of truth, with changes propagating rather than being re-announced.
- 02Development
Offline-first, then online
Hive holds a local copy of the schedule and Firestore reconciles it, so the app opens straight into content instead of a spinner. Writes queue and settle when connectivity returns, which matters on a shop floor or a back-of-house network.
- 03Strategy
Keeping the daily action one tap deep
Managers and staff use the same app for different reasons. Roles change what the home screen offers, but both land on the thing they opened it for — the current shift — without navigating for it.
Project details
- Role
- Mobile design and development
- Type
- Team scheduling application
- Stack
- Flutter, Firestore, Hive
Key features
- Single Firestore-backed schedule for shifts, swaps and availability
- Hive local cache, so the app opens into content rather than a spinner
- Writes queue offline and settle when connectivity returns
- Role-aware home screen for managers and staff
- The current shift reachable without navigating for it
Challenges
Offline-first, then online
Treating the local copy as the source the interface reads from — and Firestore as what reconciles it — is the opposite of the usual order, and it is what makes the roster readable on a back-of-house network instead of showing a loading state.
One app, two reasons to open it
Managers and staff need different things from the same data. Rather than building two apps or one cluttered one, roles change what the home screen offers while both land on the thing they actually opened it for.
The Result
A scheduling app that stays usable offline and keeps one version of the rota in front of everyone who depends on it.
What I learned
The useful reframe was that the problem was version control, not scheduling. Once the goal became one propagating source of truth rather than a better way to send a rota around, the offline-first architecture followed naturally from where the app is actually used.
Want something like this built?
Tell me what you have in mind and I will come back with a plan, a timeline and a price.