Should I vibe code
Simple booking pages, calendars, and reminders for service businesses
The appointment is a van driving to a house. Your booking form has no idea how far apart the last two jobs were.
?
Their verdict, the Pro 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
Read Calday's own industry list and the shape of the problem changes: mobile car detailing, pressure washing, garage doors, HVAC, pet sitting. These are not video calls. The appointment is a van driving across a town to an address at a time, and the two things the software has to get right are whether the technician can physically be there and whether the customer knows to be in. You will build a booking page in a sitting and it will be genuinely good. What you will not build in a sitting is travel-time buffering, a reminder job that survives its own failures, and a contact database that is quietly a record of when each of two hundred houses is empty.
What actually breaks
not "if". the specific failures.
- Travel time, which no calendar models — two jobs forty minutes apart look adjacent in a grid and are impossible in a van
- The reminder job, which fails silently by design: nothing errors when an email is never composed, and the first signal is a customer who was not home
- Buffer and duration per service, because a 30-minute consult and a four-hour detail cannot share one slot length and the version you generate will assume they do
- Daylight saving, which moves an early Sunday appointment by an hour for exactly one of the two people involved
- Cancellations and reschedules by the operator, who is holding a phone in a driveway and needs to move three jobs at once — the flow nobody builds
- The contact table, which accumulates addresses, phone numbers, access notes and visit history until it is the most valuable thing the business owns and the least backed up
- The public booking endpoint, which will be filled in by bots with plausible addresses long before it is filled in by customers
Is that you?
the verdict is a default, not a law
- One person, one service, one duration, and a calendar you look at every morning anyway
- Confirmation and reminder go out through a transactional provider whose dashboard tells you when they did not
- The contact list is backed up somewhere you could restore it from tonight
- Nobody pays anything until the job is done
- Jobs happen at customers' addresses and more than one can be booked in a day
- Someone other than you depends on the reminder arriving in order to be paid for their morning
- You take a deposit at booking — that is a different entry, and a worse one
- The client records live only in the database you are about to generate a migration for
- You cannot say what happens to bookings already in the calendar when you change a service's duration
If you build it anyway
the checklist, then the prompt that enforces it
- Give every service its own duration and its own buffer before and after, and make travel buffer a first-class field rather than something the operator remembers. The whole failure mode of field-service scheduling is two jobs that are adjacent on a grid and thirty minutes apart on a road.
- Make reminders observable. Record queued, sent and delivered per booking, and alert on the absence of sends rather than on errors — a reminder job that stops running produces no error at all.
- Store every timestamp in UTC with the IANA zone recorded next to it, and render in the viewer's zone. Test the two DST weekends explicitly; a Sunday 8am job is where it bites.
- Back the contact table up nightly to somewhere that is not the same host, and prove a restore once. For a solo trader the visit history is the business, and it has exactly one copy by default.
- Rate-limit and CAPTCHA the public booking form, and require an email confirmation click before a slot is held. Otherwise the calendar fills with junk faster than with customers.
- Treat addresses and access notes as sensitive. A row that says which afternoons a house is empty and where the key is deserves encryption at rest, a retention limit and no place in a log line.
- Build the operator's reschedule and cancel flow before the customer's booking flow. It is used far more often, from a phone, in a hurry, and it is the one you would otherwise never finish.
I am building booking software for a service business whose appointments happen
at customers' addresses. Constrain it as follows and argue with me if I skip one.
1. Ask first whether jobs are on-site. If they are, model travel: per-service
duration, a buffer before and after, and a rule that refuses to offer a slot
that leaves no travel time from the previous job. Do not treat the calendar
grid as the source of truth for feasibility.
2. Build the operator's reschedule, cancel and mark-no-show flows before the
customer-facing booking page. They are used from a phone, daily, under time
pressure, and they are the flows that never get finished otherwise.
3. Make notifications observable before making them pretty: persist a row per
reminder with queued, sent and provider-delivery state, and add a check that
alerts when the number of sends in a window drops to zero. A reminder that
never gets composed throws no exception.
4. Store all times as UTC plus the IANA zone of both parties. No fixed offsets.
Write tests for both daylight-saving transitions and for a booking made in
one zone for a service delivered in another.
5. Treat customer addresses, phone numbers and access notes as sensitive from
the first migration: encrypted at rest, out of logs and error reports, with a
stated retention period. This table lists when specific houses are empty.
6. Nightly automated backup of the contacts and bookings tables to separate
storage, plus a documented restore I can run. Show me the restore working.
7. Rate-limit the public booking endpoint per IP, require a confirmation click
before a slot is held, and expire unconfirmed holds.
8. Availability check and booking insert must be one atomic operation with a
uniqueness constraint on the slot. Two people tapping the same 9am is normal.
9. Changing a service's duration must not silently rewrite appointments already
booked. Ask me what should happen and implement whichever answer I give.
10. Out of scope: payment at booking, SMS, multi-technician dispatch. If I ask
for payment, say deposits, refunds and no-show fees are a separate project
— and that Calday is $12 a month.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
As soon as somebody else's working day depends on the reminder going out. Twelve dollars a month is well under an hour of a tradesperson's time, and one customer who was not home because a cron job died has already cost more than a year of it. The free tier covers a single service, which is genuinely enough to test whether the booking page is the thing that was slowing you down.
$12/mo is cheaper than your weekend.
Two exports keep you free: contacts with their addresses, notes and visit history, and bookings with UTC timestamps plus the IANA zone they were made in. Schedule both to somewhere off the box, weekly, from the first week — not because migration is likely but because a solo operator's client history has no second copy and no way to reconstruct it. If the booking page URL has been on a van, keep the domain and keep it redirecting.
Self-hosted appointment scheduler built for service businesses, with providers, services and durations already modelled; active work is on the develop branch.
Open-source scheduling platform; the availability and buffer logic is worth reading before you write your own.
Questions
Why is this harsher than canivibecodeit's YES?
Because they are answering whether an agent can build it, and it plainly can — a booking page with calendar sync really is one sitting. We are answering whether you should run it. The gap is not the page, it is the reminder that has to fire on the right morning for two years, the travel buffer that stops two jobs being booked across town, and the client history that exists in exactly one place.
What is actually different about field service versus a Calendly clone?
Three things. The appointment has a location, so feasibility depends on distance and not just on a free slot. The customer has to be physically present, so a missed reminder costs somebody a drive rather than a rescheduled call. And the record you accumulate is addresses and access notes rather than email addresses, which changes what a leak means.
The reminder emails work. Why keep going on about them?
Because they work right up until the scheduler stops running, and that failure emits nothing. No error, no bounce, no alert — just an ordinary quiet day followed by a customer who was at work when the van arrived. Alert on the absence of sends, not on exceptions, and this stops being the thing that gets you.
- 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 stale calendar token doesn’t throw an error. It just keeps offering slots you’re already busy in.
A booking form that asks “any conditions we should know about?” is a medical record with a submit button.
TidyCal is twenty-nine dollars once. Yours is a weekend now and a calendar-API migration every spring.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice