Shift Manager
A shift companion for restaurant managers, paused while I shipped other products.
- Role
- Solo product lead and builder
- Scope
- Problem, onboarding, briefing, chat voice, settings, and the decision to pause
- Stack
- Expo, React Native, OpenAI API, OpenWeatherMap
- Outcome
- Paused prototype after about eight days in February 2026
The problem
I ran restaurants for ten years. The hard part of a Friday night is not one big decision. It is a pile of small ones while you are already in the weeds. Someone calls off. A twelve-top walks in. The ice machine dies. A one-star review lands on your phone while you are running food.
You do not sit down for that. You have about ten seconds between tables and a phone in your pocket. Most restaurant software assumes you have a desk.
About
Shift Manager is a chat app for general managers. During onboarding it asks for your name, role, and restaurant. When you open it, a briefing card shows the weather, the cover count, and who is on. You can ask who can cover a call-off, what is 86'd, or to draft a review response. It recommends. You decide. It does not text anyone unless you say so.
I built it in February 2026 for iOS and Android. It took about eight days. Then I put it down, because I was shipping other products and I chose those instead. It is paused.
Status: Paused
The briefing on this page shows 142 covers, a Tigers game, and a server named Sarah calling off. I wrote that data so I could see the product. It is not from a live restaurant. The chat is a real model with a prompt that talks like a floor manager. The roster, the schedule photo, reviews, and a POS feed were the next things to build. I did not build them.
The core idea
A brief you can read between tables
The card at the top is the product. Greeting, weather, covers, who is on. Fifteen seconds, then you are back on the floor. Open the full brief and you get the rest: the unfilled bartender slot, overtime walking toward you, the event that will slam the door at 5:30.
Under that, a chat. Quick actions cover the things that happen every night: someone called off, who is working, start my shift, draft a review, what is 86'd.
I wrote the voice to sound like a sharp AGM texting the GM. Short. No “happy to help.” If the night is going to be a grind, it says so.
Screens
How it works
Set up the shift
Name, role, restaurant, and optional location. The second screen says it takes 30 seconds. That was the point.
Read the brief
Weather, covers, who is on, and anything flagged. Meant to be scannable in about fifteen seconds.
Ask, then decide
A call-off, an 86, a review. The app suggests the next move. The manager still sends the text.
How it's built
01
Onboarding
Name, role, restaurant, and permissions. Stored on the device in AsyncStorage.
02
Briefing card
The shift brief at the top of chat. Service numbers in the current build are sample data.
03
Chat
GPT-4o streams a reply using a prompt written in restaurant language, not assistant language.
04
Quick actions
Call-off, who's working, start shift, review draft, what's 86'd. Each one prefills the composer.
05
Weather
If location is on, OpenWeatherMap fills the brief. Cached for 15 minutes.
06
Not wired yet
Live roster, parsed schedules, reviews, local events, and a POS feed.
Settings also has a 100-meter geofence and an auto-brief on arrival toggle. Those controls exist in the UI. They do not yet run against a live restaurant.
Key decisions
Chat instead of another dashboard
A manager on the floor is standing up. A message you can fire off between tables beat a screen full of tiles.
Recommend, then wait
The prompt can suggest who should cover. It cannot text them until the manager says so. I have been the person whose name is on the result. I was not going to let an app text my staff for me.
Write sample service data so the brief could be judged
I needed to see what a real night would look like before I had a restaurant's numbers. The 142 covers and the Sarah call-off are written examples. An empty state would have hidden whether the brief was even useful.
Stop after eight days
Finishing means a roster, a schedule, reviews, and a restaurant that will actually use it. I did not have that customer, and other products were already in stores. I paused it rather than decorate the demo.
Why it paused
I was working on other projects. That is the reason. Ripple, Yapper, and the rest were live work. This one was a prototype with no restaurant behind it yet.
I still think a manager should be able to ask a phone what the night looks like without sitting down at a computer.
What went wrong
The next build needs a real roster and a real schedule, from a restaurant that will use them. Without that, more features would be more demo. The geofence, the auto-brief, and the review drafting are designed. They are not connected to live data.
The chat also asks for an OpenAI key in Settings. That is fine for a prototype I run myself. It is not how you give this to a restaurant.
What's built
- About 8 days
- from first commit on February 14, 2026 to the last one on February 22.
- iOS and Android
- one Expo app. The briefing, chat, onboarding, and settings screens are in the build.
- Streaming chat
- a real GPT-4o reply, with a prompt written to talk like a floor manager, not a help desk.
- Sample briefing data
- 142 covers, Sarah calling off, a Tigers game. Written so the brief could be designed. Not from a live restaurant.
- Not wired
- live roster, parsed schedules, reviews, local events, and a POS connection.
With more resources
The next work is a restaurant that will let me load a real roster and a real schedule. Until that exists, this stays paused. If I picked it back up, I would start there, not with more screens.