For years, I paid for scheduling tools that couldn’t access my own calendar. This is how one calendar flag led to building my own booking site, which later became the booking system for Sierra Nevada Off Road Academy.
The question no one could ask
My calendars are on iCloud. Some are shared with my wife, others with family - for work, pets, baby appointments, dentist visits, and our March trip. Every scheduling tool I tried just guessed at my availability. Calendly guessed. Cal.com guessed. Acuity guessed, and charged me $60 a month for it. I was completely fed up.
What made it worse was that the solution should have been simple. On an Exchange server, you mark yourself as busy or free, and every tool respects that. Apple has a similar flag on each event, but there is no way to ask iCloud if you are free right now, and no easy way to manage that flag manually.
The more I looked, the worse it got. About one in ten of my events had no busy/free flag at all. None of the events my wife created had it either. So even when the flag was there, it was unreliable. The tool I needed didn’t exist, and the platform couldn’t answer the most basic scheduling question.
Proving Apple would play along
Before building on iCloud, I needed to make sure the basics would work. So the team built a simple tool that does one thing: it sets the busy/free flag on an event using CalDAV, changes nothing else, and backs up the event first.
The tool passed all 11 tests, even the tricky one where it had to change just one instance of a recurring event.
Two important things came from that work. First, Apple does honor the flag. If you change one instance of a repeating event, Apple Calendar shows only that one as free while the others stay busy. I saw this happen in real time on a shared calendar I was monitoring.
The second point is even more important: changing the flag didn’t notify anyone on the events I use it for. I ran sixteen updates on events with real attendees, and no emails were sent. I also tested on a shared calendar with my wife, with notifications turned on. Five flag changes, and her phone stayed silent. But when I created or deleted a test event, she got notified right away. There’s one exception. If the person on the invite also shares the calendar with me, Apple can treat the change as a revision and re-invite them, so the tool skips those events. For my own events and for shared events without accepted attendees, the rule is clear: changing busy/free is invisible, but creating or deleting events is not.
That became the foundation. Each day, I don’t ask iCloud if I’m free, because it won’t answer. Instead, I use an engine that reads the flag along with other inputs and figures it out. So I stopped waiting for Apple and built my own solution.
I wrote up the CalDAV work and the findings separately, for anyone who wants the mechanics: icloud-caldav-freebusy on GitHub.
A booking site that actually knows when I’m free
That engine made cal.cjarnesen.com possible. It’s a booking page that checks my real calendar before offering a slot: it looks at the flag, overlays, blackout dates, existing bookings, and the buffers I want between meetings. Only when everything is clear does a time show up as available.
Some design choices are worth highlighting, because they make the difference between a regular booking page and one you can actually trust.
The system is designed to fail safely. If the calendar sync is out of date, the site doesn’t offer any slots instead of guessing. If the server goes down, I might lose a booking, but it will never cause a double-booking.
People who book never see event titles. The web role can’t access them at all - this is enforced in the database, not just in the app code.
A booking isn’t just a copy of my calendar; it’s a layer on top of it. When you book, the site creates a unique Zoom link, sends you a confirmation with a calendar file, and adds an attendee-free event to my real calendar. After that, the calendar controls the booking. If I delete the event, the booking is canceled. If I move it, the booking reschedules and everyone gets updated. I’ve run the whole process end to end on a real booking, including a cancellation, and watched every piece tear down clean - even the Zoom link goes dead on Zoom’s end.
Doing it at scale for SNVORA
Once I trusted the system for my own calendar, the next step was to use it for SNVORA. Instead of just moving the old signup process to new tech, I rebuilt the entire customer experience starting from the calendar.
With one-click class offers, I can list six classes on the same day. The first paid signup locks the day to that class and removes the other offers. If the last booking on a locked day is canceled, the day unlocks and the other offers return. For multi-day classes, each day takes a seat, which most scheduling tools I tried didn’t handle correctly.
For VIP signups, a teammate or I can register a customer in the background and send them one link to complete their waiver and details. Payment can be by Zelle, check, cash, or comped, and the link skips the payment screen when needed. The same link puts the customer into the real waiver flow, so the legally sensitive part is never a second-rate copy.
Digital waivers have a real audit trail. They are e-signed without a vendor. Each signed waiver records the signer’s IP, the consent version, and confirmations for twelve sections. The customer gets a copy by email, and a PDF is automatically saved in the business records. The web role is designed so it cannot access any medical answers.
The checkout process is complete: it supports discount codes, gift certificates, add-ons, and refunds as store credit. If a credit covers the full class cost, the customer never sees a payment screen.
Everything runs on our own domain. There are no iframes or vendor pages pretending to be ours. The only third-party page customers see is Stripe’s payment page, which is intentional so we never handle card data.
The admin is conflict-aware. When I add class dates to the offer calendar, any day that overlaps with my personal calendar is flagged before I publish. I can still offer the date if I want; the override is one click and gets logged. The prompt appears while I’m offering dates, which is when it actually helps - not after someone has already booked.
The calendar keeps its own roster. Every class appears on the shared business calendar with the roster in the notes: names, contacts, vehicles, and add-ons. Medical details are never included in these notes. The Google Sheet roster I used to manage by hand is now created automatically. I no longer have to copy names or check boxes as paper waivers arrive.
Now I can audit email delivery. Status updates come back for each recipient through webhooks and appear on a console I can check. We no longer have to CC ourselves on every message and hope it was delivered.
What it cost to get here
None of this happened smoothly, and I wouldn’t want to pretend it did.
The morning I remember most was when the system sent about 1,100 emails for a single booking between 4 and 9 a.m. A kill switch I had built ahead of time stopped it, and the system was back up the same day, but only after it proved three clean sync sweeps. There were stranger bugs too. Once, a drag-to-reschedule tried to move a 2026 booking to 2007 because it misread a daylight-saving rule. For a while, every Zoom link sent people to my personal meeting room with the passcode 1234. Each issue happened because my test version of the calendar was simpler than the real iCloud, and reality was more complicated.
The number that stands out is the SNVORA rebuild. I built it in eight days. If I had done it the usual way, it probably would have cost $10,000 and taken two months.
Owning the stack
In the end, it means no borrowed domains, no vendor-branded screens, and no monthly fee for a tool that guesses my calendar. SNVORA handles bookings on its own system, true to the brand, and I have a personal booking site that really knows when I’m free.
It all started with a single calendar flag that Apple set but wouldn’t let anyone query. If you want to see how everything else works day to day, check out the Inside page.