How to build a restaurant staff scheduling app your managers will actually use

Most restaurant schedules start life as a spreadsheet on the manager's laptop. Every Thursday someone copies last week's tab, moves a few names around, prints it, pins it next to the walk-in and texts a photo to the group chat. Then the swap requests start: "can anyone take my Saturday double?" in the group chat, a sticky note on the printout, a verbal "yeah, fine" from a sous chef who isn't the one who approves swaps.

It works until it doesn't. Someone works a shift that isn't on any version of the schedule. Overtime shows up on payroll that nobody saw coming. A server says they told you about their exam week, and they probably did, in a text you can't find.

Off-the-shelf scheduling apps solve a lot of this, and if one fits, use it. This post is for the restaurants where they don't quite fit: split shifts that the app treats as two days, stations that don't map to "roles", a group with three locations and a shared pool of cooks, or an owner who just doesn't want another per-user subscription. Here's how to build your own scheduling app with an AI app builder, step by step, with the prompts you'd actually type.

I'll use Mythex because it's what I work on, but the thinking applies to any builder.

Step 1: Write down how your schedule really works

Before the first prompt, spend ten minutes answering these. Every answer becomes a sentence in your prompt, and every unanswered one becomes a guess.

1. What's a shift? Restaurants don't schedule "days", they schedule services. Lunch 10:30–3, dinner 4–close, brunch on weekends. A double is two shifts, not one long one, because people can swap half of it.
2. What decides who can work a shift? Usually the station: grill, sauté, pantry, dish, bar, server, host, expo. One person can cover several. A new hire can't close the bar alone.
3. Who changes what? Staff set availability and request time off. Staff can offer a shift for a swap. A manager approves swaps and time off. The GM sees labor hours.
4. What does the manager check first? Usually two things: "is every service covered?" and "is anyone heading for overtime?". Those become the home screen.

If your location has a predictive scheduling law, write that down too. Several US cities (New York, San Francisco, Seattle, Chicago, Philadelphia, Los Angeles among them) and the state of Oregon have "fair workweek" rules that require posting schedules in advance and paying a premium for late changes. The details differ by city, so check yours, but it's a good reason to have the app record when each version of the schedule was published.

Step 2: The first prompt

Paste your answers in almost as written. A long prompt is fine.

Build a staff scheduling app for a restaurant. Staff have a name, phone, email, the stations they can work (grill, sauté, pantry, dish, bar, server, host, expo) and a weekly hours target. Managers create shifts on a week calendar: each shift has a date, a service (brunch, lunch, dinner), a station, a start and end time, and one assigned person. Staff log in to see their own shifts, set weekly availability, request time off and offer a shift for swap. Another qualified staff member can pick up an offered shift, and a manager must approve it. The manager's home page shows uncovered shifts for the week and each person's scheduled hours, with anyone over 40 hours highlighted.

In a few minutes you'll have a working preview with a database behind it. Before you judge how it looks, click through it as a line cook would on their phone, then as a manager on a laptop.

Step 3: Check the data model before you touch the design

Three mistakes show up in almost every first version of a scheduling app. Fix them now, before real shifts go in.

• Swaps should be records, not edits. If a swap just changes the name on a shift, you lose who originally had it and who approved the change. Ask for a swap request table: shift, offered by, picked up by, status, approved by, timestamps.
• Stations should limit who can be assigned. If the assign dropdown lists everyone, someone will end up on grill who has never worked grill.
• Hours should be calculated. Scheduled hours per person per week should come from the shifts, not from a number someone types in.

Store shift swaps as separate requests linked to the shift, with who offered it, who picked it up, the status (offered, picked up, approved, declined) and who approved it. When assigning a shift, only show staff qualified for that station who haven't marked themselves unavailable at that time. Calculate weekly scheduled hours per person from their shifts.

Step 4: Bring your current staff list in

You don't need to retype anyone. Export your staff spreadsheet as CSV and tell the builder what to do with it:

Import this CSV into the staff table. The "Positions" column contains station names separated by commas. Show me a preview of the first ten rows before saving anything.

Asking for a preview first is a good habit. It catches a column of phone numbers that got read as dates before it's 40 rows of nonsense.

Step 5: Build the two screens people use every day

Resist adding features. A scheduling app lives or dies on two screens.

For staff, on a phone: "my next shifts", a button to offer one for swap, a list of shifts they could pick up, and their time-off requests. Big text, no tables.

Make the staff view mobile-first: a list of my upcoming shifts with date, service, station and times, a button on each to offer it for swap, a section "shifts you can pick up" filtered to my stations, and my time-off requests with their status.

For managers: the week grid, with gaps in red and overtime in amber, and a queue of pending swaps and time-off requests to approve in one tap.

On the manager's week view, show services as rows and days as columns, with each station's assigned person in the cell. Empty cells are red. Add an approvals panel listing pending swaps and time-off requests with approve and decline buttons.

Then add one thing that removes a real job: a "publish week" button that locks the schedule, records when it was published, and lets staff see it. Edits after publishing get logged with a reason. If you're under a fair workweek rule, that log is the record you'll want.

Step 6: Test it as three people

Make three test accounts and walk through a real week.

1. As a server: Can you see only your shifts? Can you edit someone else's? (You shouldn't.) Offer your Saturday dinner for swap.
2. As a second server: Do you see the offered shift? If you're not qualified for that station, you shouldn't. Pick it up.
3. As the manager: Approve the swap. Check that the shift now shows the new person, the request shows who approved it, and both people's weekly hours changed.

Then try the awkward cases: a shift that crosses midnight, two people picking up the same offered shift, a time-off request for a day someone is already scheduled. If something is wrong, describe what you saw ("a server can open the edit button on another server's shift"), not the fix you imagine.

Step 7: Publish it so only your team can open it

A schedule has phone numbers and availability on it, so it shouldn't be public. On Mythex's Business plan you can publish an app as members-only: only signed-in people in your team workspace can open it. You can put it on your own subdomain (something like schedule.yourrestaurant.com) so staff can save it to their home screen. If your managers use Google Workspace, you can verify your domain and let them sign in with their work accounts.

What you end up with

• A web app with a real Postgres database, shift history and a log of every swap and approval.
• Staff sign-in, with staff, manager and owner roles.
• A mobile view your team can actually use between tickets.
• Members-only access and team sign-in on the Business plan, a custom domain from Pro up.
• The code, which you can edit or export if you ever hand it to a developer.

Honest limits

• Payroll and POS integrations take work. Exporting hours as CSV for your payroll provider is easy. Live two-way sync with a POS or time clock is a project, and it depends on whether that system has an API you can use.
• Notifications need setup. Email notifications for new schedules and approved swaps can be added. SMS needs a provider account (Twilio or similar), which you'd set up and pay for.
• You still have to check labor rules. The app can highlight overtime and log late changes. It can't tell you what your city requires.
• Someone has to own it. One manager should own changes to the app. That's far less work than maintaining a spreadsheet, but it isn't zero.

For restaurant groups

If you run more than one location, add a location to each shift and each staff member, and let managers see only their own location while the owner sees all of them. The restaurant staff scheduling page has a starting prompt you can copy. If several managers will build and maintain tools together, the Business plan on the pricing page gives you a shared workspace, roles and members-only apps. There's a Free plan to try the build first.

If your schedule has a rule this post didn't cover, describe it in the comments and I'll suggest how to put it in the prompt.