Shiftboard
Rota planning for small cafés, with swaps in two taps
About
My sister runs a café and planned shifts in a group chat. Shiftboard is the tool I built for her: a weekly rota, availability from each person, and shift swaps that need one tap from each side and none from the manager.
38 cafés in Spain and Portugal use it now. Built almost entirely in Lovable, with Claude helping me think through the rules for swaps and overtime.
How it was made
Shared by the maker. Numbers are their own estimate.
- Build time
- 10 days
- AI spend
- $60
- Prompts
- ~150
- Written by AI
- 97%
Agents
Lovable
82% of the workThe app, end to end
Claude
18% of the workSwap rules, edge cases and support replies
Build recipe
The code isn’t public. This is the whole project as one prompt: paste it into your own agent to build the same thing.
Written by Claude
From the project’s code and history · 371 words
Build a web app called Shiftboard: rota planning for small cafés, with swaps in two taps.
What it does
My sister runs a café and planned shifts in a group chat. Shiftboard is the tool I built for her: a weekly rota, availability from each person, and shift swaps that need one tap from each side and none from the manager.
Stack
Use React, Supabase, Stripe. The original was built with Lovable and Claude in 10 days, for about $60 in AI usage.
How it fits together
- A server-rendered web app with a small API layer
- A database for user data, with row level security on every table
- Sign-in so each person only sees their own data
Build it in this order
- Set up the project, the database and sign-in, and deploy an empty page
- Build the main screen with realistic sample data
- Connect it to real data and add the one action the app exists for
- Add the empty states and error messages a new user will hit
- Write tests for anything that touches money, dates or other people's data
A prompt that worked: Find the edge cases before your users do
Here are the rules for shift swaps in our café app (pasted below). Act as a tired café manager on a Saturday morning. List 15 situations where these rules produce a result that feels unfair or confusing, ordered by how often they'd happen. For each, suggest the smallest rule change that fixes it.
Watch out for
- Don't build settings, teams or billing before the main screen works
- Keep the first screen useful with sample data, so the app makes sense before anyone has set it up
Done when
- A new user can sign in and get value in under two minutes
- Everything works on a phone
- Tests pass for the core logic
Before writing code, ask me up to five questions about who this internal tools web app is for and what the first version must do. Then work in small steps: after each one, tell me how to try it and wait for my feedback.
Discussion
3 comments
- Amara Okafor2 days ago
Copied the main prompt and adapted it for a project at work. Saved me an afternoon.
- Kenji Mori1 day ago
What did the agent struggle with most? Always curious where people had to step in.
More like this
Paste a README, get honest notes on what a stranger won't understand