Why We Shipped iCal Instead of Google OAuth — and What Three Failed Iterations Taught Us
Every coworking operator I’ve talked to has the same workflow for checking desk coverage: open two tabs. One for OhMyDesk (or whatever booking tool they use), one for Google Calendar. Cross-reference manually. Mentally subtract the two people you know are working remotely this week.
It’s tedious and error-prone. The fix is obvious: sync the booking system to the calendar. So when we decided to build calendar sync, I wrote up a spec for the obvious path — Google Calendar OAuth.
Then I read the spec back and realised I was about to spend three weeks building something 40% of operators couldn’t use.
Why iCal first
Google Calendar OAuth means your members connect their Google accounts to OhMyDesk. Nice in theory. In practice:
- Operators at spaces in Eastern Europe, the Balkans, and Central Europe use a mix of Google Calendar, Outlook (often through Microsoft 365 company accounts), and Apple Calendar. Any OAuth-first approach immediately excludes two of the three.
- The auth flow is a liability for a tool used by solo operators running 10-desk spaces. “Connect your Google account” is a conversion step that drops the cohort who uses Outlook or Apple Calendar.
- Google’s OAuth approval process for calendar write access requires a security review, privacy policy review, and a verified domain. Reasonable requirements — but a 2–3 week gate before you can ship anything.
iCal (the .ics subscription format) is different. Every calendar app on earth has supported it for twenty years. It’s just a URL that returns a text file. Paste the URL into Google Calendar, Outlook, Apple Calendar, Thunderbird, Fastmail — they all subscribe to it and poll for updates automatically.
No OAuth. No app approval. No account linking. One URL, works everywhere.
So we built the iCal feed. From decision to deployed: 24 hours.
Iteration 1: The banner explosion
The first version was technically correct and practically unusable.
A member with a 30-day dedicated desk plan got 30 calendar events — one per booked day. Each event was titled “Alexey Safonov — Desk 4.” Every day for a month, stacked in the grid.
Open your calendar for May and imagine every single day has a banner across it. Then multiply by however many members you have.
Two operators flagged it within the first hour of using it. One sent a screenshot of Apple Calendar looking like a barcode.
The logic was right. The default was wrong. A 30-day plan is not 30 events — it’s one booking run with a start and an end.
Iteration 2: The single span
The obvious fix: one event per booking run. Instead of 30 daily events, one event from May 1 to May 31.
We shipped it. Then the feedback came back, and it was subtler.
One operator put it well: “I don’t need to see that Alexey is booked from May 1 to 31. I already know that. What I need to know is when he arrives and when his plan ends — because those are the two days I have to think about.”
She was right. The 30-day single event is technically accurate but information-free. Every day looks the same. Nothing jumps out. The calendar becomes wallpaper.
Iteration 3: Arrivals and departures (the one that stuck)
The third model turned out to be the right one: instead of modelling the booking as a span, model it as two markers.
- [ARRIVAL] - Alexey Safonov on the first day of the plan
- [ENDS] - Alexey Safonov on the last day of the plan
Thirty days of occupancy becomes two events. Your calendar stays readable. The days that matter — the transition points — are the only ones that show up.
A few details that make this work:
Short titles, full details in the body. The event title is short enough to read in a week grid ([ARRIVAL] - Alexey Safo…). The event body has everything: full name, desk number, plan type, full run dates, space name. Open the event and you have the full picture.
Transparent events. The bookings are marked transparent in the iCal spec, which means they don’t block your free/busy availability. If someone invites you to a meeting, the booking events don’t make you look busy — because you’re not, the member is.
Optional reminders. Some operators want a heads-up before a plan ends so they can chase renewal. A toggle in Settings enables a reminder — 15 minutes to 2 days before, your choice.
Token rotation. The feed URL is private. If it ever leaks, one click in Settings generates a new token and invalidates the old one.
What the default teaches you
The arrivals-and-departures model isn’t just a better default — it’s a different mental model for what “calendar sync” means for a coworking space.
You’re not trying to visualise every day of occupancy in your personal calendar. You have a booking tool for that. What you want from your calendar is transition events: the moments when something changes. When someone arrives. When someone’s plan ends and you need to renew, replace, or rebook.
Booking tools think in terms of occupancy. Calendars are better at surfacing moments.
The first two iterations were optimised for occupancy. The third is optimised for moments. That’s why it works.
How to subscribe
If you’re already on OhMyDesk: go to Settings → Integrations, find the Calendar sync card, copy your iCal URL, and paste it into your calendar app of choice.
- Google Calendar: left sidebar → Other calendars → + → From URL
- Apple Calendar: File → New Calendar Subscription → paste URL
- Outlook (web/Microsoft 365): Add calendar → Subscribe from web → paste URL
The feed updates roughly every hour. There’s a toggle to switch between arrivals-and-departures (default) and all-booked-days if you want full coverage.
More on the feature at /features/calendar-sync/.
The next phase of calendar sync — Google Calendar OAuth two-way sync, for operators who want write access — is on the roadmap. We’ll build it once an operator asks for it. Nobody has yet, which tells us the iCal approach is doing its job.