Shift swap board for hourly teams

A web app where hourly staff post and claim shift swaps themselves, with rule checks and one-tap manager approval instead of a chaotic group chat.

The idea

A small web app that sits next to whatever scheduling system a business already uses and handles only one thing: shift swaps. An employee who can't work Thursday posts the shift to a board. Anyone qualified for that role sees it, claims it, and the app checks the swap against a few rules — overtime threshold, required certification, minimum rest between shifts — before sending the manager a single approve/deny notification. The schedule of record gets updated on approval, and everyone involved gets a confirmation.

The point is that swaps are the messy 10% of scheduling that full workforce-management suites handle badly and that group chats handle not at all.

Why build this

Restaurants, clinics, retail stores, and warehouses with 20–200 hourly staff overwhelmingly publish schedules in one system and negotiate changes in a WhatsApp or Slack group. The failure mode is familiar: two people claim the same shift, nobody tells the manager, the covering employee crosses into overtime, or an unqualified person takes a shift that legally needs a certification. The manager finds out on the day.

Existing tools either bundle swaps into a $6-per-employee-per-month suite that the business won't switch to, or ignore the workflow. A standalone tool that imports the schedule, owns swaps, and writes back is a much easier sell — it doesn't ask anyone to migrate. Scheduling APIs from Deputy, 7shifts, and Homebase are open enough to read and write shifts, and predictive-scheduling laws in a growing list of cities now require an audit trail of who changed what and when, which a group chat cannot produce.

Stack sketch

Frontend: SvelteKit, installed as a PWA. Staff use phones on the floor; a PWA avoids app store review and lets you ship daily.
Backend: Node with Fastify, Postgres via Drizzle. Swap eligibility is a pure function over shift + employee rows, so it is trivially unit-testable.
Auth: phone number plus one-time code through Twilio Verify. Hourly staff often have no work email; do not build a password flow.
Notifications: WhatsApp Business API or SMS for staff, plus a Slack app for managers who live there.
Integrations: REST clients for 7shifts and Deputy behind a thin SchedulingProvider interface, plus a CSV import fallback so a business can start in ten minutes without IT involvement.
Rules engine: plain TypeScript predicates in a table — max_weekly_hours, min_rest_hours, required_skill — evaluated per candidate and returned with human-readable reasons.
Hosting: Fly.io with a managed Postgres. Traffic is spiky around shift-publish day and near zero otherwise.

Scope for v1

In:

CSV schedule import and one live integration (pick 7shifts — the API is clean and the segment is dense).
Post a shift, browse open shifts, claim a shift.
Three rules: overtime threshold, minimum rest, role match.
Manager approval queue with the rule check results shown inline.
SMS notification on post, claim, and decision.
Immutable audit log of every swap event.

Out: shift bidding, availability collection, time clock, payroll, multi-location org charts, native apps, and any attempt to become the scheduling system itself. Resist that last one specifically — the moment you own the schedule you inherit forecasting, labor budgets, and compliance reporting.

Where it could go

The obvious next step is partial shifts: someone needs to leave at 3pm, not skip the whole day. Splitting a shift into two claimable halves is a small data model change and a large increase in how often the tool gets used.

After that, ranked auto-approval. Once you have a few thousand approved swaps, most of them are boring — same role, no overtime, well-rested employee — and a manager approving them adds nothing but delay. Let a business define a rule set that auto-approves the safe cases and only escalates the ambiguous ones. That turns a notification tool into something that actually removes work.

Longer term, the audit log is the real product for multi-location operators. A view showing which locations run on constant swaps, which employees consistently pick up coverage, and which shifts nobody ever wants is genuine scheduling intelligence, and it costs nothing extra to collect.

Watch out for

The compliance surface is sharper than it looks — overtime and rest rules vary by state and by union contract, so make the rule set data, never hardcoded, and be careful about implying the app guarantees legal compliance. The other risk is integration write-back: several scheduling APIs let you create shifts but not cleanly reassign them, so verify the exact update path for each provider before promising two-way sync.