Eén codebase. Vijf platforms. Twee app stores. Vier browsers.

Verzonden binnen drie weken.

Cal.com ging altijd al over het ontmoeten van mensen waar ze al zijn.

Voor planning betekent dat overal: op je telefoon, in je browser, in het tabblad dat je nooit sluit, op de laptop die je voor werk gebruikt en op het apparaat dat je pakt als je de deur uit rent.

Velen van jullie hebben erom gevraagd en we hebben eindelijk besloten het te proberen. Deze week hebben we aangekondigd:

• Een native iOS-app

• Een native Android-app

• Een Chrome-extensie

• Een Firefox-extensie

• Een Safari-extensie

• Een Edge-extensie

En we hebben dit niet in maanden of kwartalen gedaan.

We hebben dit allemaal binnen minder dan drie weken van idee tot productie verzonden.

Alles zonder het product te splitsen in een dozijn repositories die na verloop van tijd langzaam van elkaar afdrijven.

We deden het met één codebase.

Het kernidee: verscheep Cal.com overal zonder Cal.com vijf keer te verschepen

Historisch gezien leven “mobiele app” en “browserextensie” in verschillende universums.

• Mobiel wil React Native, native build-tools, app store-workflows, pushmeldingen, dieplinkjes, enzovoort.

• Extensies willen inhoudscripts, achtergrond-/servicewerkers, toestemmingen, opslag-API's, browser-eigenaardigheden en het nooit eindigende “werkt in Chrome maar…” spel.

De gebruikelijke aanpak is om de splitsing te accepteren:

• aparte teams

• aparte stacks

• aparte releaseprocessen

• aparte bugs

• aparte UI-inconsistenties

Dat voelde niet als de Cal.com manier.

We wilden dat Cal overal als hetzelfde product zou aanvoelen. Dezelfde UI. Hetzelfde mentale model. Dezelfde functies. Dezelfde snelheid van iteratie.

Dus bouwden we het zo.

iOS + Android: aangedreven door de nieuwste Expo en React Native

Onze iOS- en Android-apps worden aangedreven door de nieuwste Expo (expo.dev) en React Native (RN).

Expo heeft een punt bereikt waar je het beste van twee werelden krijgt:

• uitstekende ontwikkelaarservaring

• serieuze productiereadiness

• flexibiliteit wanneer je native wilt gaan

Het belangrijkst is dat Expo past in een groter idee waar we veel om geven:

Web en native zouden niet als afzonderlijke producten moeten aanvoelen.

Ze zouden aan moeten voelen als verschillende oppervlaktes van hetzelfde systeem.

Extensies: aangedreven door WXT

Voor browserextensies hebben we gebouwd op wxt.dev.

Extensies zijn nog steeds een van die gebieden waar tools zich vreemd verouderd kunnen aanvoelen. WXT maakt het modern:

• heldere structuur

• verstandige standaardwaarden

• betrouwbare multi-browser builds

En ja, we hebben gebouwd voor Chrome, Firefox, Safari en Edge.

Alleen Safari is meestal al genoeg om teams af te schrikken van multi-browserondersteuning. Maar het doel was nooit “Chrome nu, anderen later.”

Het doel was Cal overal.

Het leuke deel: Chrome-extensie UI aangedreven door Expo Web

Hier is het deel dat nog steeds een beetje onwerkelijk aanvoelt:

Onze Chrome-extensie UI wordt aangedreven door Expo Web.

Dat betekent dat de extensie-UI geen aparte frontend is met zijn eigen componentensysteem en stylingverschillen. Het is gebouwd met behulp van dezelfde UI-aanpak die we al gebruiken voor mobiel, draaiend op het web binnen de extensie-oppervlakte.

Dus als ik zeg één codebase, bedoel ik het op een manier die daadwerkelijk telt:

• gedeelde schermen

• gedeelde componenten

• gedeelde ontwerpelementen

• gedeelde logica

• gedeelde snelheid

De WXT app zelf draait binnen /extension/entrypoints/content.ts wat vervolgens de expo-web app als een iframe laadt. Dit is de meest gebruikelijke aanpak om "zijbalk" Chrome-extensies te bouwen en ik leerde deze truc van Wilson Wilson (@euboid). Helaas heeft de officiële Chrome-extensie "popup" een maximale hoogte van 600px.

We hebben zelfs wat browser-only API's ingebouwd, zoals het injecteren van onze Cal.com widget in mail.google.com en calendar.google.com, wat gemakkelijk kan worden gedaan in de /extensions map van WXT.

Uit mijn ervaring blijkt deze combinatie: native iOS + Android via Expo, multi-browserextensies via WXT, extensie UI via Expo Web, allemaal samen gevoegd in één coherent codebase iets dat ik persoonlijk nog niet eerder op deze manier heb gezien.

Misschien bestaat het ergens. Het internet is groot.

Maar ik heb het niet gezien, en er was zeker geen draaiboek dat we konden volgen.

Dus maakten we ons eigen.

Minder dan 3 weken… omdat de basis goed was

Zo snel verschepen ging niet over heldendaden of overwerk.

Het ging erom de juiste basis te hebben.

Alles vertrouwt op de nieuwste en beste Cal.com API v2, die OAuth gebruikt voor autorisatie. Dat betekende:

• heldere authenticatiestromen

• veilige toegang

• een consistent model over apps en extensies

• geen hacks, geen shortcuts

Dezelfde API drijft mobiel, web en extensies aan. Geen “alleen extensie-eindpunten.” Geen “mobiele uitzonderingen.”

Gewoon één API, ontworpen om mee te schalen met het ecosysteem.

👉 Als je apps of integraties bouwt bovenop Cal.com, is dit je startpunt:
https://cal.com/help/apps-and-integrations/oauth

Die OAuth-basis maakt het realistisch om zo snel nieuwe planningsapps te verschepen zonder concessies te doen aan beveiliging of ontwikkelaarssaniteit.

Waarom dit belangrijk is (naast “kijk wat we gebouwd hebben”)

Verschepen naar veel platforms is alleen indrukwekkend als het onderhoudbaar blijft.

De echte winst is niet de checklist van platforms. De echte winst is:

• Consistentie: functies landen overal, niet “mobiel eerst, extensie later”

• Snelheid: één plek om te bouwen, één plek om te repareren

• Kwaliteit: minder platformspecifieke afwijkingen

• Momentum: het team bouwt product in plaats van verbindingscode

Extensies laten ons direct binnen workflows leven. Mobiel laat ons in de echte wereld leven. Samen wordt dat oppervlak tot een productvoordeel.

Krediet waar het verschuldigd is

Dit gebeurde niet door één persoon. Maar twee mensen waren enorme vermenigvuldigers:

• Wilson Wilson (@euboid), een enorme hoeveelheid van de browserextensie-ondersteuning, cross-browser randgevallen en “dit is de truc die echt werkt” kennis kwam van Wilson.

• Beto (@betomoedano), veel van de Expo-expertise en praktische hulp die “dit zou moeten werken” omzet in “ziet er goed uit, voelt goed” kwam van Beto.

• en het hardwerkende team bij call namelijk: ikzelf, Dhairyashil Shinde, Carina Wollendorfer en

  Volnei Munhoz en Claude Code.

Dank jullie allemaal. Echt waar.

Wat is de volgende stap

Grappig feit: Onze apps zijn nog niet live gegaan, wat nogal hilarisch is. Het App Store-registratieproces duurt langer dan de hele app-ontwikkeling zelf. Om de een of andere reden zijn er nog steeds KYC-problemen met ons bedrijf (we hebben een paar jaar geleden een naamswijziging ondergaan, mismatch van D-U-N-S-nummer, niet-Amerikaanse werknemer die een Amerikaans bedrijf beheert, bla bla bla.)

Soms wou ik dat mobiele app-ontwikkeling hetzelfde tempo zou kunnen ervaren dat we gewend zijn op het web, maar dat is zeer onwaarschijnlijk.

Hoe dan ook, alsjeblieft meld je aan voor onze wachtlijst op cal.com/app en wordt op de hoogte gebracht zodra de productapps live gaan in de winkels. Volgens het registratie-team zijn het nog maar een paar dagen, maar de feestdagen komen eraan, dus je weet maar nooit.

De codebase is nog steeds behoorlijk rommelig met grote componenten, maar we maken die nu schoon.

Uiteindelijk is het meest opwindende deel om “Cal.com overal” te krijgen met zo weinig ingenieurswerk dat nodig is om het te onderhouden.

Het is dat we nu een basis hebben waar het verzenden van het volgende voelt zoals het zou moeten:

• bouw het een keer

• verscheep het overal

• itereren snel

Dat is de norm.

En het is een behoorlijk leuke norm om te halen.