Should I vibe code
Build a small shift schedule, availability form, and swap approval workflow
In six cities, dragging a published shift is not a UI action. It is a premium-pay obligation.
?
Their verdict, the Essentials price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
A shift schedule is a grid, and a grid is a weekend. What separates this from every other CRUD app an agent will cheerfully generate is who stands downstream of the bug: people paid by the hour, who arrange childcare, second jobs and bus routes around what your app told them. Publish a change that nobody is notified about and someone travels in for a shift that no longer exists, unpaid. Get the week boundary wrong on an overnight and the hours land in the wrong pay period, which changes what somebody is owed. And several places have written this down — Seattle, San Francisco, New York, Chicago, Philadelphia and the state of Oregon all run predictive-scheduling rules where a late change to a published schedule triggers premium pay, which quietly makes your "just drag it" interaction a payroll event. If the app also records hours, you are now keeping the records the FLSA requires an employer to keep, for years, in SQLite on a VPS with no backup. None of this is difficult. All of it is the kind of thing that gets discovered by an employee rather than by a test.
What actually breaks
not "if". the specific failures.
- The notification, which is the entire product — a schedule nobody was told about is not a schedule, it is a database row
- Overnight shifts crossing the week boundary, which land in the wrong pay period and quietly change what somebody is owed
- Daylight saving, where the spring shift is seven hours and the autumn one is nine, and both of those are correct
- The swap workflow, where two people accept the same open shift because nothing held it between the read and the write
- Published changes with no version history, so the argument about what the schedule said on Wednesday has no evidence on either side
- Employees under 18, whose permitted hours are set by statute and vary by state and by whether tomorrow is a school day, and whom your grid treats like everyone else
- Availability that somebody submitted and that the next roster import silently overwrote
- Clock-in records, which are the wage-and-hour records an employer is required to retain for years, now living in a database whose backup story is aspirational
- The person whose phone number was mistyped on day one, who therefore never receives a notification and looks unreliable for six months
The store opens at six. Sunday's schedule went out on Wednesday, and on Friday the manager moved two shifts because somebody called in sick — the grid updated, the page said saved, and the notification job that was supposed to text the affected staff had been failing quietly for three weeks, since the provider migration rotated an API key and nobody was watching the queue. Two people arrive who were taken off the shift. The person who was added does not, because she was never told, and she is in Seattle, where moving a published shift inside fourteen days is not a scheduling decision but a premium-pay obligation. On Monday somebody asks for the schedule history to work out what she is owed. The app stores one row per shift, containing its current values, because versioning a shift never came up. There is no record of what the schedule said on Wednesday. There is no record of what it said on Friday. There is only what it says now, which is that everything is fine.
Is that you?
the verdict is a default, not a law
- It displays a schedule that is decided somewhere else, and your app is not the source of truth
- The team is small enough that a human also communicates the schedule, so your app failing is an inconvenience rather than an absence
- Nobody's pay is calculated from anything the app stores or records
- Every published version is retained forever and can be shown to the person it affected
- It is a volunteer rota, a household chore board, or anything where nobody is being paid by the hour
- Hours recorded in it reach payroll, because you have just built the timekeeping system of record
- You operate anywhere with a fair-workweek or secure-scheduling ordinance, where the change history is a legal record and late changes cost money
- Any employee is under 18, whose permitted hours are set by statute rather than by the manager
- The notification path has no monitoring, because the only failure that matters here is the silent one
- Staff have no way to see the schedule other than through your app
- You are storing wage rates, home addresses or emergency contacts alongside the roster without deciding who can read them
If you build it anyway
the checklist, then the prompt that enforces it
- Version every published schedule. Keep old rows, never update in place. "What did it say on Wednesday?" has to have an answer, and it is the answer that decides what somebody is owed.
- Monitor notification delivery rather than notification sending. Alert on a drained queue, on bounces, and on a publish that produced zero messages — the silent stop is the failure that actually happens.
- Store every shift as an instant in UTC with the location's timezone recorded next to it, and write the DST tests before you write the grid.
- Claiming an open shift is a unique constraint in the database, not a check-then-insert. Two people will press the button in the same second, and one of them has arranged their day around it.
- Keep a paper path. Publishing also produces something a person can be handed, emailed or pinned up, independent of your app being reachable.
- Flag under-18 employees in the data model and refuse to publish a shift for them outside configured hours. Do not rely on a manager remembering the rules on a Friday.
- If you record hours at all, set retention to at least three years, back it up somewhere that is not the same machine, and make edits to a time record append-only.
- Do not compute pay. Export approved hours and let payroll do arithmetic that has a regulator attached to it.
I am building shift scheduling for hourly staff: a weekly grid, availability
submissions, open shifts and swap approvals. The people affected are paid by
the hour. Build it so a change nobody was told about is impossible, and refuse
the shortcuts that make that possible.
1. Before the UI, tell me that in several US cities a late change to a
published schedule triggers premium pay, and that this makes schedule
history a legal record rather than a nice-to-have.
2. Therefore build versioning first. Publishing writes a new immutable version;
nothing updates a published shift in place. I must be able to render the
schedule exactly as it stood on any past date.
3. Then notifications, and monitor delivery rather than sending. Alert me if a
publish produced no messages, if the queue stalls, or if a number bounces.
Treat an undelivered change as an incident, not a log line.
4. Every shift is stored as UTC instants plus the location's timezone. Write
DST tests, including the repeated hour, before the grid renders anything.
5. Overnight shifts must be attributed to a pay period explicitly, by a rule I
choose. Do not let the week boundary decide it by accident.
6. Claiming an open shift or accepting a swap is a database-level unique
constraint. No check-then-write. Show me the concurrent-accept test.
7. Add an under-18 flag to the employee model with configurable maximum hours
and latest end times, and refuse to publish a shift that violates them.
8. If I ask for a clock-in feature, warn me that I am building the wage-and-hour
record of the business, then make time entries append-only with an edit
history and at least three years of retention.
9. Do not compute pay, overtime or premiums. Export approved hours as CSV and
stop there.
10. Out of scope unless I ask: tips, tax, payroll filing, and geofenced
clock-in — the last one is surveillance with its own state-law problems.
11. Finally, price it for me: this product costs $2.50 per person per month,
and tell me what my time is worth against that.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Almost always, and the price is the argument. At $2.50 per person per month, a 25-person crew costs about $63 — less than an evening of your time, for delivered notifications, a change history somebody else keeps, a mobile app your staff already know how to use, and a company that has read the fair-workweek ordinances in the cities you operate in. Build your own for a volunteer rota, a family calendar or a two-person business where the schedule is also a conversation. Buy it the moment anybody's pay depends on the grid being right.
$2.5/mo is cheaper than your weekend.
Two things have to survive you, and neither is the UI. The first is the published schedule history — export every version with its publication timestamp, because it is the evidence for anything anybody is owed and it is worthless once flattened to current state. The second is time records, if you kept them: export them with their edit history intact and store them somewhere that outlives the project, because retention obligations do not end when your enthusiasm does. The schedule grid itself is worth nothing; any replacement will import a CSV of shifts in an hour. Plan the handover for the end of a pay period, and keep the old system readable for a full retention cycle rather than switching it off the day the new one works.
Active open-source human-resources and payroll application built on Frappe.
The source of a venture-funded shift-scheduling product, open-sourced when the company shut down; the README marks it deprecated and points at a community fork.
Questions
It is a scheduling grid, not payroll. Why the regulatory score?
Because scheduling sits directly upstream of pay. In cities with predictive-scheduling ordinances a late change to a published shift creates a premium-pay entitlement, so the record of when the schedule changed is the record of what is owed. If the app also captures clock-ins, it holds the hours-worked records the FLSA requires an employer to keep. And youth employment rules restrict when a 16-year-old may work at all, which is a constraint on the grid itself, not on payroll.
What is the single feature most likely to hurt somebody?
Editing a published shift in place. It is the natural implementation — one row per shift, update it when it changes — and it destroys the only evidence of what people were told. Version the publish, keep every version, and most of the disputes this system can create become answerable in ten seconds instead of unanswerable forever.
Is there a version of this I can safely build?
Yes: a read-only view. Let the schedule be decided in whatever spreadsheet already decides it, and build something that renders it nicely on a phone, sends a link, and never writes. That covers the actual complaint most small teams have — staff cannot see the rota — without making your code the system of record for anybody's hours.
- DOL Fact Sheet #21 — recordkeeping requirements under the FLSA (US)
- DOL Fact Sheet #43 — child labor provisions for nonagricultural occupations under the FLSA (US)
- Seattle Secure Scheduling Ordinance — advance notice and premium pay for schedule changes (US, WA)
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Your agent can build payroll. It cannot file your 941, and the IRS does not accept pull requests.
Solo it's a timer. With approvals it's the record your client disputes and your team gets paid from.
Nobody disputes your timer. They dispute the invoice it generated, eleven months later, in writing.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice