Tweeted this earlier today. The fragmented calendar mess exists because everyone is solving scheduling with the wrong primitive.
A calendar event has two values. Start and end. That's an interval on a one-dimensional axis. A conflict between two events is interval overlap. That's a 1D collision detection problem. Physics engines have solved this for fifty years. Interval trees, sweep-and-prune, segment trees, all mature with O(log n) queries and clean composition.
What does the calendar industry use. An events table, a foreign key to a calendar, and SELECT WHERE start less than end AND end greater than start. That works for one calendar with no time zones, no recurring events, no transparency states. Add anything real and the relational primitive collapses.
Recurring events. Store them expanded and your table grows infinitely. Store them as a rule and every query needs an expansion step that no SQL engine is good at. Time zones. Events have a wall-clock time that drifts with DST, or an absolute time that displays differently per participant. Most schemas pick one and ship bugs against the other. Free/busy. Should be a derived view from interval overlaps. Most tools store it as a denormalized column that drifts the moment you change anything upstream. Multi-calendar merge. Each provider has different concepts of busy, tentative, working location, focus time. The only way to reconcile them is to poll all of them and normalize in memory. Which is what every Cal.com clone is doing right now, badly.
The reason nobody fixes it is that calendars are a monopoly market. Google, Microsoft, Apple. Each owns a relational store. Each has decided their schema is the world. The right primitive (interval tree as the storage layer, event-sourced timeline, a CRDT of intervals, pick your flavor) requires rewriting from scratch, and nobody wants to compete with Google Calendar on calendar. So all the innovation happens in wrappers. Calendly, Cal.com, Reclaim, Motion. Each one inherits twenty years of broken primitives and tries to UI its way around them.
Change my mind. If you're building scheduling in 2026 and your data model is "events table with foreign key to calendar," you've inherited twenty years of debt nobody profits from. The interesting product to build isn't another wrapper. It's an interval-native timeline that ingests calendars as one of many sources and treats free/busy as a derived view, not a stored column.
I'm not going to build it. I'm building something else. But somebody should.
— Simon