What this is
The stack you’d reach for if you were cloning Cal.com today, meeting scheduling, booking pages, paid bookings, host payouts. Cal.com is open source (github.com/calcom/cal.com) so the real production stack is verifiable, not guessed at.
When to pick this stack
- You’re building a vertical SaaS that revolves around scheduling, bookings, or any time-sliced resource (consultations, classes, equipment, rooms)
- You want a real Postgres database (relations, transactions, foreign keys), not a document store
- You expect the app to grow well past a free tier and want infrastructure that scales without a re-platforming project at the 6-month mark
What we’d swap
- Neon → Supabase: if you also need auth and storage, Supabase folds those in. Cal.com itself uses NextAuth + raw Postgres, but for fresh builds Supabase Auth saves a week.
- Resend → Postmark: roughly equivalent for transactional email. Resend’s API is more developer-pleasant; Postmark has a longer deliverability track record.
- PostHog → Plausible: PostHog gives you product analytics + feature flags + session replay. If you only need basic privacy-friendly traffic counts, Plausible is dramatically simpler and cheaper.
What this won’t cover
Cal.com itself maintains a complex booking engine, calendar sync (Google Calendar, Microsoft Graph, iCal), and embedded “atoms” SDK. The stack here gives you the runtime; the engine is the work you’re shipping.