Should I vibe code
Booking pages, staff calendars, reminders, payments, and classes
The double-booking isn't yours to apologise for. It's a stylist, at 9am, with two people booked into one chair.
?
Their verdict, the Pro (month-to-month) 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
Four scheduling tools already have entries here and each one broke somewhere different: Acuity on the health questions in the intake form, Appointlet on daylight saving, OnceHub on routing rules that fail silently, Book Like A Boss on the refund you now owe. Setmore's difference is who is standing there. Its free tier covers four users and its paid tier is unlimited, because what it sells to a salon, a garage or a physio practice is not your booking page — it is four other people's, over one shared calendar, on phones, all day. That changes the shape of every bug in the system. Your slot arithmetic is no longer wrong at you; it is wrong at a stylist who has never heard of your repo, standing in a shop at nine in the morning with two clients booked into one chair, and the fix is not a deploy, it is her apologising to a stranger. Underneath that sit two things the single-person schedulers do not have. The first is concurrency: with several staff and a public page, two bookings can land three hundred milliseconds apart, and the gap between "this slot looked free" and "the event is written" is a real race that a weekend project resolves by hoping. The second is that Setmore is a till — Stripe, Square, PayPal, Tap to Pay, deposits, a cash register — and it sells a separately-configured HIPAA product for the practices that need one. You can build the booking page. You are building rather more than a booking page.
What actually breaks
not "if". the specific failures.
- The double-booking race. Two people load the same free slot, both submit, and unless the write is a conditional insert inside a transaction with an exclusion constraint, both succeed — and the person who finds out is a member of staff with two clients in front of them
- Shift patterns, which are where multi-staff scheduling actually lives: lunch breaks, split shifts, someone finishing at 3pm on Thursdays, holidays, one person covering two locations. None of it is in a Calendly-shaped model and all of it is in the real business
- Buffer and duration arithmetic per service and per staff member. A 90-minute treatment with a 15-minute clean-down is not the same availability calculation as a 30-minute chat, and getting it wrong overlaps the day by a few minutes at a time until the last appointment is an hour late
- Calendar refresh tokens, one per staff member, held for people who never agreed to your error handling. When one expires, that person's availability is silently wrong and only they will notice
- Reminders, which are the feature the business is actually buying. An SMS that does not fire is a no-show, a no-show is lost revenue, and a cron host that restarted at 4am fails at this without a single error in a log anyone reads
- Deposits and no-show fees, where your database and your payment provider are two systems that can disagree. When they do, someone holds a receipt for an appointment that does not exist
- Cancellations and reschedules, which are most of real-world booking traffic and where refunds, partial refunds and coupon reuse all meet at once
- The intake form, the moment a therapy or medical practice uses it, because "anything we should know before your visit?" turns a booking table into a health record
The Saturday morning rush books out in about forty minutes. Two of them land on the same 09:30 with the same stylist, eleven seconds apart, because the availability check and the insert are separate queries and nothing in between them holds a lock. Both customers get a confirmation. Both get an SMS reminder at 08:30. At 09:28 there are two people in the shop expecting the same chair, and the person handling it is a stylist who did not write your code, cannot see your database, and has no way to tell which booking came first. She takes one and offers the other a free cut. Meanwhile the deposits are the interesting part: both cards were charged at booking, one refund goes out that morning, and the other sits pending for five working days while the customer, who was turned away, watches their bank. The Google review names the salon.
Is that you?
the verdict is a default, not a law
- It books one person's time — yours — from your own calendar, with no staff, no payments and no intake questions beyond a name and an email
- The people using it can see the underlying calendar directly and can fix a bad booking themselves in ten seconds
- It is internal: colleagues booking a meeting room or a piece of equipment, where a clash is an inconvenience rather than a customer
- Availability is derived from a single source of truth and written with a database constraint that makes an overlap impossible rather than unlikely
- Staff other than you depend on it to know where to be, because the failure lands on them in front of a customer
- Money moves at booking — deposits, prepayment, no-show fees — since every scheduling bug then arrives attached to a refund
- The intake form asks anything medical, and it will the moment a therapist, physio or clinic uses it
- There is no unique constraint or exclusion constraint in the database preventing overlapping bookings, and the plan is to check availability first and insert second
- Reminders are the point and there is no monitoring proving they went out
- Somebody's business hours are being modelled as an integer range, because real ones are not
If you build it anyway
the checklist, then the prompt that enforces it
- Make overlaps impossible at the database, not in application code: an exclusion constraint on staff plus time range, and a booking insert that fails loudly rather than a check-then-write that races.
- Store every time as UTC with the originating IANA timezone alongside it, and derive display from that. Never store a local wall-clock time without its zone, and test the two DST weekends in both directions.
- Model availability as staff-level rules — shifts, breaks, holidays, per-service durations and buffers — before you draw a single calendar grid. That model is the product.
- Make every write idempotent with a client-supplied key, because the customer on a bad phone connection will press book three times.
- Keep money out of it as long as possible. If deposits are required, use a hosted checkout so you never see a card number, and reconcile provider state against your bookings on a schedule rather than trusting the webhook that may not arrive.
- Monitor reminders as a first-class thing: a queue, retries, a dead-letter, and an alert when the expected send count for a day is zero. Silent failure here is indistinguishable from a quiet week.
- Give staff a manual override that works without you — block time, cancel, move a booking — because they will need it on a Saturday and you will be unreachable.
- Keep the intake form to a name, contact details and a note field with a stated purpose, and if anyone asks for medical questions, read the Acuity entry before agreeing.
I am building an appointment booking system for a small business with several
staff: a public booking page, staff calendars, reminders and deposits. Build it
in this order and refuse the shortcuts.
1. Before any UI, design the data model for availability: staff, services with
durations and buffers, shift patterns, breaks, holidays, and blocked time.
Show me how a split shift and a bank holiday are represented.
2. All timestamps stored in UTC with the originating IANA timezone kept
alongside. Write the DST tests first — spring forward and autumn back, in
both hemispheres — and show me them passing before anything is bookable.
3. Prevent double-booking in the database: a Postgres exclusion constraint on
staff and time range, inside a transaction. If I suggest checking
availability and then inserting, refuse and explain the race — the person
who discovers it is a member of staff standing in front of a customer.
4. Make the booking write idempotent with a client-supplied key. Assume every
customer double-taps on a bad connection.
5. Then cancellation and rescheduling, before confirmation emails. They are the
majority of real traffic and they are what everyone builds last.
6. Then reminders, as a queue with retries, a dead-letter and an alert when a
day's expected send count is zero — silent failure looks like a quiet week.
7. Only then payments, and only via hosted checkout. Never touch a card number.
Reconcile provider state against bookings on a schedule and tell me what
happens when a webhook never arrives.
8. Refuse to build a refund path that fires automatically on cancellation until
I have written down the cancellation policy in plain English.
9. Give staff an override that works without me: block time, move, cancel.
10. Keep the intake form to name, contact and a purpose-limited note. If I ask
for medical questions, stop and tell me what that makes the database.
11. Out of scope and say so: classes with seat counts, recurring appointments,
round-robin assignment and multi-location. Then tell me Setmore is $12 a
user month-to-month and $5 annually, and that four users are free.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
Buy the moment somebody who is not you needs it to be right. Setmore is free for four users, which is most small businesses on this page, and twelve dollars a seat month-to-month after that — against which you are weighing shift patterns, DST, a booking race, a reminder queue that must never silently stop, and a refund path. The reminders alone justify it: a missed SMS is a no-show, and a no-show is a real number of pounds that shows up in the same week you shipped the change. Build your own if it books one person's time, no money changes hands, and the intake form asks for a name.
$12/mo is cheaper than your weekend.
The export that matters is the future, not the past: everything booked from today onwards, with the customer's contact details, the service, the staff member and the timezone, in a format you could hand to Setmore or Cal.com on a Tuesday afternoon. Keep bookings in your own database as the source of truth and treat any external calendar as a mirror you can rebuild, because the reverse — Google as the record — means your exit is a pile of events with your formatting in the description field. Two things need archiving rather than exporting: the payment records, which have to survive for as long as your tax authority says, and the intake notes, which should ideally not need archiving at all because you never collected anything worth keeping.
Mature open-source scheduling platform with multi-user availability and payment integrations already solved.
Self-hosted booking system built around staff, services and working plans, which is the model most homemade versions miss.
Questions
There are already four scheduling entries. What does this one add?
Staff. The others assume you are scheduling yourself, and their failure modes are correspondingly personal — a timezone slip, a routing rule that matched nothing, a refund. Setmore's free tier is four users and its paid tier is unlimited, because the business it sells to has people in it. Once several staff share one calendar, the interesting bug is concurrency rather than arithmetic, and the person who absorbs it is an employee in front of a customer rather than you in front of a laptop.
How do I actually stop double-booking?
In the database, not in your code. Postgres exclusion constraints over a staff ID and a time range will refuse an overlapping insert at the storage layer, so the race between checking availability and writing the booking simply cannot be lost. Everything else — advisory locks, serialisable transactions, optimistic retries — is a variation on the same principle, which is that the check and the write must be the same operation. A read followed by an insert works perfectly in testing and fails on the first busy Saturday.
Setmore sells a separate HIPAA product. Does that matter to me?
It matters as a signal about the intake form. Vendors carve HIPAA into its own product with its own agreement because it is a set of ongoing operational commitments — access controls, audit logs, breach notification, a signed BAA — rather than a feature flag. If a therapist, physio or clinic starts using your booking page, the question "is there anything we should know before your appointment?" turns your bookings table into health records overnight, and nothing about your weekend changed. The Acuity entry is the long version of this.
What is the failure people never plan for?
The reminder that did not send. Everything else in this system fails loudly — a broken booking page gets reported within the hour. A reminder queue that stopped after a host restart produces no error anyone reads, and the symptom is a Tuesday with three no-shows, which looks exactly like a quiet Tuesday. Alert on the absence of sends, not just on failures.
- PCI DSS document library (PCI Security Standards Council)
- Stripe — reducing your PCI scope
- GDPR Art. 5 — principles relating to processing of personal data
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.
A booking form that asks “any conditions we should know about?” is a medical record with a submit button.
Timezone maths is the product, not a feature. It goes wrong twice a year, silently, in someone else's calendar.
A booking link that takes a deposit is a shop. Refunds, no-shows and coupon codes are your accounting now.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice