Shiftboard

Rota planning for small cafés, with swaps in two taps

Mateo RuizLaunched 2 weeks agoWeb appWorking · checked 3 hours ago
0:42

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 work

    The app, end to end

  • Claude

    18% of the work

    Swap rules, edge cases and support replies

MCP servers

No MCP servers. Built with the agents alone.

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

  1. Set up the project, the database and sign-in, and deploy an empty page
  2. Build the main screen with realistic sample data
  3. Connect it to real data and add the one action the app exists for
  4. Add the empty states and error messages a new user will hit
  5. 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.

    • Mateo RuizMaker2 hours ago

      Thanks! Good question, I'll write it up in the build log this week.