Apps, not features: why we built an App Store into the product
Scheduling doesn't happen in isolation. It happens across calendars, video tools, and payment providers. So we stopped bolting integrations onto the product and started treating them as first-class apps you install.
Every scheduling workflow eventually collides with the rest of your stack. A meeting isn't just a time slot — it's a calendar event, a video link, sometimes an invoice, sometimes a reminder pushed to a CRM. For a long time, we treated each of those touchpoints as a config screen buried in settings. That worked when the list was short. It doesn't anymore.
So we rebuilt integrations around a simpler idea: apps you install.
Why an App Store, and not more settings pages
The honest answer is that "integrations" had become a catch-all category, and catch-alls rot. A user connecting Google Calendar and a user connecting a payment provider have almost nothing in common — different permissions, different failure modes, different reasons to care. Stuffing them into the same settings tab meant every new integration made the experience slightly worse for everyone.
Modeling each integration as an installable app lets us give it its own surface area: a details page that explains what it does, what it touches, and what happens when you turn it on Install an App. It also gives us a clean unit to ship against. Adding a new provider no longer means finding real estate in a settings menu — it means publishing an app.
What this unlocks
The immediate win is discoverability. You can browse what's available in one place — calendar providers, video tools, payment integrations — instead of hunting through docs to find out whether we support the thing you use Install an App. If we support it, it's in the store. If it's not in the store, we don't support it yet. That's a contract we couldn't make before.
The less visible win is consistency. Every app now goes through the same install flow, which means the same shape of consent, the same shape of configuration, and — importantly — the same shape of uninstall. Turning an integration off used to be an adventure. Now it's the inverse of turning it on.
There's also a roadmap implication worth being upfront about: treating integrations as apps is what lets us keep adding them without the product getting heavier. The surface stays the same; the catalog grows.
What's next
We're starting with the integrations most of you already asked for, and we'll be adding to the catalog steadily rather than in big-bang batches. If there's a provider you want to see in the store, tell us — the whole point of this refactor was to make "add another one" a small decision instead of a large one. Setup instructions for each app live in the help center.