File
SMF·CAL-COM-TEAMS
Received on
31.07.2026
Reviewed on
28.09.2026
Exhibits annexed
3
Questions
4

SMF·CAL-COM-TEAMS

Can a prompt replace Cal.com Teams?

Scheduling — booking links and calendar automation

Almost Verdict recorded on 28.09.2026 · Verified on 31.07.2026
Price
$15/moSource: cal.com · Checked on July 31, 2026
Per year
$180
Build time
A week
Category
Scheduling
Votes
0 votes
YesAlmost (checked)Not yet

Exhibit tracking slip

Exhibit A The prompt
Exhibit B What you lose
Exhibit C Why people still pay: calendar integrations and reliability
Exhibit Q Questions

Verdict

Cal.com itself is open source, so the most honest DIY path for a lot of people is literally self-hosting the real project via its own Docker setup. This prompt is for building a smaller, purpose-built booking page from scratch instead — a real weekend project if you only need one calendar and simple availability rules. What a from-scratch build gives up either way at the personal-project level: multiple calendar providers, team round-robin routing, and payments.

Exhibit B — What you lose

Exhibit A — The prompt

Received on31.07.2026
Build a single-user booking page: connect one Google Calendar via OAuth, publish available time slots computed from configurable working hours, a minimum-notice window, and a booking horizon, and let a visitor reserve a conflict-free slot without creating an account. Use Next.js/TypeScript with Google Calendar's OAuth and Calendar API, and Postgres to store the account's settings and booking records. Calculate availability by fetching busy blocks from the connected calendar, subtracting them from configured working hours, and rendering the result in the visitor's browser-detected timezone (compute everything server-side in UTC first). When a visitor books, create the event transactionally — check for conflicts and write the calendar event in one step to avoid a race that double-books the same slot under concurrent requests. Send a confirmation email with a signed cancel/reschedule link (no login required) via a transactional email provider. Support exactly one event type (a fixed duration and description) rather than Cal.com's multiple configurable event types. Do not build support for Outlook or Apple Calendar, team/round-robin routing, or payment collection — those are explicitly out of scope; self-hosting the real open-source Cal.com is the better answer if you need them. Needs a Google OAuth app (free to register), a domain to host the booking page, and a transactional email provider for confirmations.

Opening prefills the prompt — press enter to run it.

Exhibit B — What you lose

  • B.1 multiple calendar providers (Outlook, Apple)
  • B.2 team round-robin and collective routing
  • B.3 payment collection on booking
  • B.4 years of timezone edge-case fixes

Prior art

Exhibit C — Why people still pay: calendar integrations and reliability

Booking software earns its keep on the day a timezone bug or a double-booked slot costs a client relationship — reliability under edge cases is worth more than the visible form.

Questions

Why not just self-host the real Cal.com?

For a team that needs its full feature set, that's honestly the better move — it's open source. This build is for a single-user booking page smaller and simpler than running the whole project.

Does it support Outlook or Apple Calendar?

No — only Google Calendar in this build. Supporting multiple providers is real, ongoing engineering work the prompt deliberately skips.

Can two people book the same slot at once?

The transactional booking step is specifically designed to prevent that — one request wins, the other sees the slot as taken, checked at write time rather than only in the UI.

What does it cost to run?

A domain, minimal hosting, and a transactional email provider's free tier covers typical personal booking volume — realistically a few dollars a month or less.

Receipt

Already built this yourself?