One codebase. Five platforms. Two app stores. Four browsers.

Shipped in under three weeks.

Cal.com has always been about meeting people where they already are.

For scheduling, that means everywhere: on your phone, in your browser, in the tab you never close, on the laptop you use for work, and on the device you grab when you’re running out the door.

A lot of you have asked for it and we finally decided to give it a try. This week we announced:

• A native iOS app

• A native Android app

• A Chrome extension

• A Firefox extension

• A Safari extension

• An Edge extension

And we didn’t do this over months or quarters.

We shipped all of this in less than three weeks from idea to production.

All without forking the product into a dozen repos that slowly drift apart over time.

We did it with one codebase.

The core idea: ship Cal.com everywhere without shipping Cal.com five times

Historically, “mobile app” and “browser extension” live in different universes.

• Mobile wants React Native, native build tooling, app store workflows, push notifications, deep linking, etc.

• Extensions want content scripts, background/service workers, permissions, storage APIs, browser quirks, and the never-ending “works in Chrome but…” game.

The usual approach is to accept the split:

• separate teams

• separate stacks

• separate release processes

• separate bugs

• separate UI inconsistencies

That didn’t feel like the Cal.com way.

We wanted Cal to feel like the same product everywhere. Same UI. Same mental model. Same features. Same speed of iteration.

So we built it like that.

iOS + Android: powered by the latest Expo and React Native

Our iOS and Android apps are powered by the latest Expo (expo.dev) and React Native (RN).

Expo has reached a point where you get the best of both worlds:

• excellent developer experience

• serious production readiness

• flexibility when you need to go native

Most importantly, Expo fits a bigger thesis we care deeply about:

Web and native shouldn’t feel like separate products.

They should feel like different surfaces of the same system.

Extensions: powered by WXT

For browser extensions, we built on wxt.dev.

Extensions are still one of those areas where tooling can feel oddly stuck in the past. WXT makes it feel modern:

• clean structure

• sane defaults

• reliable multi-browser builds

And yes, we built for Chrome, Firefox, Safari, and Edge.

Safari alone is usually enough to scare teams away from multi-browser support. But the goal was never “Chrome now, others later.”

The goal was Cal everywhere.

The fun part: Chrome extension UI powered by Expo Web

Here’s the part that still feels slightly surreal:

Our Chrome extension UI is powered by Expo Web.

That means the extension UI isn’t a separate frontend with its own component system and styling drift. It’s built using the same UI approach we already use for mobile running on the web inside the extension surface.

So when I say one codebase, I mean it in a way that actually matters:

• shared screens

• shared components

• shared design primitives

• shared logic

• shared velocity

The WXT app itself runs inside /extension/entrypoints/content.ts which then loads the expo-web app as an iframe. This is the most common approach to build "sidebar" chrome extensions and I learned this trick by Wilson Wilson (@euboid). Sadly the official chrome extension "popup" has a max-height of 600px.

We've even sprinkled in some browser-only APIs such as injecting our Cal.com widget into mail.google.com and calendar.google.com which can easily be done in the /extensions folder from WXT.

From my experience, this combination: native iOS + Android via Expo, multi-browser extensions via WXT, extension UI via Expo Web, all tied together in one coherent codebase is something I personally haven’t seen done like this before.

Maybe it exists somewhere. The internet is big.

But I haven’t seen it, and there definitely wasn’t a playbook we could follow.

So we made our own.

Less than 3 weeks… because the foundation was right

Shipping this fast wasn’t about heroics or crunch.

It was about having the right foundation.

Everything relies on the latest-and-greatest Cal.com API v2, which uses OAuth for authorization. That meant:

• clean auth flows

• secure access

• a consistent model across apps and extensions

• no hacks, no shortcuts

The same API powers mobile, web, and extensions. No “extension-only endpoints.” No “mobile exceptions.”

Just one API, designed to scale with the ecosystem.

👉 If you’re building apps or integrations on top of Cal.com, this is your starting point:
https://cal.com/help/apps-and-integrations/oauth

That OAuth foundation is what makes it realistic to ship new scheduling apps so quickly without compromising security or developer sanity.

Why this matters (beyond “look what we built”)

Shipping to many platforms is only impressive if it stays maintainable.

The real win isn’t the checklist of platforms. The real win is:

• Consistency: features land everywhere, not “mobile first, extension later”

• Speed: one place to build, one place to fix

• Quality: fewer platform-specific divergences

• Momentum: the team builds product instead of glue code

Extensions let us live directly inside workflows. Mobile lets us live in the real world. Together, that surface area becomes a product advantage.

Credits where they’re due

This didn’t happen because of one person. But two people were massive multipliers:

• Wilson Wilson (@euboid), a huge amount of the browser extension support, cross-browser edge cases, and “this is the trick that actually works” knowledge came from Wilson.

• Beto (@betomoedano), tons of the Expo expertise and practical help that turns “this should work” into “looks good, feels good” came from Beto.

• and the hardworking team at call namely: myself, Dhairyashil Shinde, Carina Wollendorfer and

  Volnei Munhoz and Claude Code.

Thank you all. Seriously.

What’s next

Fun fact: Our apps have not gone live yet, which is quiet hilarious. The App Store enrolment process is taking longer than the entire app development itself. For some reason there are still KYC issues with our company (we renamed a few years ago, mismatch of D-U-N-S number, non-US employee controlling a US company, bla bla bla.)

Sometimes I wish mobile app development could experience the same pace that we are used on the web but that is very unlikely.

Anyway, pleeease sign up for our waitlist on cal.com/app and be notified once the production apps go live in the stores. According to the Enrolment team it's only a few more days but the holidays are coming up so you never know.

The codebase is still quiet messy with large components but we're cleaning those up now.

In the end, the most exciting part is getting to “Cal.com everywhere” with such little engineering overhead to maintain.

It’s that now we have a foundation where shipping the next thing feels the way it should:

• build it once

• ship it everywhere

• iterate fast

That’s the bar.

And it’s a pretty fun bar to clear.