Recently, I started diving into Cal.com, an open-source scheduling platform used globally.
And honestly, it’s like taking a masterclass in how modern software is actually built, not just talked about.
Here’s what I’ve been learning so far 👇
1. Monorepos + Workspaces + Turborepo = Sanity for Large Projects
Cal.com uses a monorepo setup managed by Turborepo, and this part completely changed how I think about structuring codebases.
Inside the repo, you’ll find multiple “apps”, like the main web app, backend, and other internal tools, all living together, sharing common packages (like UI components, config files, and utilities).
Workspaces make this connection seamless. If you fix a bug in a shared package, every app gets the update instantly, no reinstalling, no broken links.
And Turborepo? It’s like a smart manager that caches build results and only rebuilds what’s changed.
That’s how Cal.com keeps developer experience fast even in a huge codebase.
2. Package Managers: npm, yarn, pnpm — Why So Many?
Before this, I thought package managers were just “install commands.”
But Cal.com uses yarn, and I finally realized it’s more than just speed, it’s about efficiency and consistency.
Unlike npm, yarn uses a virtual filesystem to link packages directly. This drastically reduces disk usage and improves startup speed. When you’re managing multiple apps in a monorepo, this small optimization saves massive build time.
Now I get why big teams switch, it’s not a “hipster” choice, it’s a practical one.
3. Testing Big Projects with Vitest & Playwright
In small projects, you can “trust yourself.”
But in massive products, trust isn’t enough, you need tests that confirm reality.
Cal.com uses Vitest (a lightweight, fast unit testing framework) and Playwright (for end-to-end browser tests).
Vitest ensures each function and component behaves as expected.
Playwright simulates real user actions like “book a meeting,” “cancel,” or “update timezone”, ensuring nothing breaks after new features.
It taught me the importance of test layering:
Unit tests → verify logic
Integration tests → verify data flow
E2E tests → verify user experience
This isn’t just about quality, it’s about confidence in every deploy
4. Folder Structure That Scales, Not Scares
Opening Cal.com’s folder tree is like entering a library, not a junkyard.
Everything has a place.
Frontend? /apps/web
Backend? /apps/api
Shared logic? /packages/
Even configs (like .env, ESLint, Tailwind) are centralized and consistent.
This taught me that folder structure is a silent mentor, it trains developers to think in modular, isolated systems.
Bad structure costs time. Good structure saves it.
5. Prisma ORM + tRPC: The TypeScript Dream Team
Now this blew my mind.
Instead of writing APIs the traditional way, routes, controllers, schemas, etc. Cal.com connects backend and frontend using tRPC.
It lets you call backend functions directly from frontend with full type safety.
No need for REST or GraphQL boilerplate.
Combine that with Prisma ORM, and you have a database layer that’s both elegant and predictable.
I could literally see the benefits, clean models, migrations, and queries that auto-complete.
The result? Type-safe APIs from database to UI, an entire chain of trust.
6. i18n — The World Isn’t Just “en-US”
I always ignored i18n until I saw it done properly.
Cal.com supports multiple languages and the logic behind it is clean and reusable.
They use translation files (like en.json, fr.json) and a function that dynamically loads language based on user preference or browser settings.
It taught me that internationalization is not a late-stage feature, it’s part of your architecture.
Because “Hello” means nothing if your users only read “Hola”.
7. Docker & Docker Compose — One Command to Rule All Devs
Setting up large projects is usually painful: install this, configure that, pray it runs.
Cal.com simplifies that using Docker and Docker Compose.
Running docker-compose up spins up the entire environment, backend, frontend, database, everything.
Every developer gets the same setup, ensuring no “works on my machine” moments.
This made me realize Docker isn’t just for deployment, it’s for developer sanity too.
8. AI in Real Dev Workflow — Not Just a Buzzword
One thing that stood out, Cal.com uses Cursor AI and other AI tools to speed up their development flow.
They integrate it where it actually helps, not for marketing.
AI assists in refactoring, writing test cases, and code suggestions.
It’s a glimpse of how teams are already merging human expertise with AI efficiency.
We’re not competing with AI, we’re collaborating with it.
9. Configs, Environments & Sentry — The Unsung Heroes of Scale
When you dig into their configs, you realize how much thought goes into managing environments.
There are clear .env.development, .env.production setups, and robust fallback systems.
Sentry integration tracks errors across environments with exact stack traces.
This showed me what “production-grade” actually means:
No hidden config surprises, no manual tweaks, no chaos.
Final Thought — Learning by Reading
Every folder I opened taught me something, not through tutorials, but through context.
It’s one thing to read about “scalable folder structures,” and another to see one live in a project powering thousands of users.
This experience reminded me that real learning happens in the wild, in codebases that are used, updated, and improved daily.
I’m documenting what I learn from each of these concepts like how Turborepo caching works internally, how tRPC builds end-to-end type safety, or how Docker simplifies team onboarding.
I’ll be breaking each of them down in future posts on my blog.Because sometimes, the best classroom isn’t a course, it’s a well-written repo.
Stay tuned… next, I’ll dive deep into how Cal.com uses Turborepo to manage its monorepo architecture efficiently.
If you found this blog post helpful, make sure to follow me for more insights. Also, check out my social media handles where I regularly share valuable content:
Thanks for reading…
