Build your own Calendly: 6 hours to the first booking, then the real work
On a Saturday night I handed an AI coding agent the spec for my own booking app. By 03:22 I had booked myself from my phone. This is the night log: what the checks found, what the app does now, and what it costs to run.
- Yes, you can build your own Calendly with AI, and it books real calls. I handed over a spec at 21:27 on a Saturday. At 03:22 I booked myself from my phone, with a Google Meet link and an invitation from my own address.
- The build was the cheap part. 14 separate agents then reviewed or attacked it and found what the passing tests missed, like a declined invitation that kept the slot blocked.
- What it does now: 2 meeting types, conflict checks against my calendar (room for 5 more Google accounts), two-way Google sync, reminders, signed webhooks, an embed and a full admin.
- It is not cheaper than free. Mine runs on about 5 USD a month, cal.com's free plan costs nothing. You build for control: your design, your address, your data.
- Downloads: the spec I handed over and the pre-launch checklist that came out of the night.
01The night I built my own Calendly
Book, my app, is a booking page for one person: me. A visitor picks a time, the app checks my Google Calendar, creates the event with a Google Meet link and Google sends the invitation from my own address. No accounts, no team features. The next day it became the "Book a call" button on this site.
The spec was mine: Astro on Cloudflare, Supabase as the database, Google's APIs called directly, slot rules that survive clock changes. Claude Code did the building, phase by phase. The page design came first, and it took 3 rejected concepts before I said what I meant: "you are missing the point, the page should be simpler, less words." The final layout is one I had made earlier in Codex, rebuilt in this site's design system around my office photo.
- I hand over the spec: "let me know if this is doable."
- 3 concepts in, I ask for fewer words.
- Design final. Plan approved 14 minutes later.
- First version on book.crmmeister.com, a placeholder.
- First break test reports back.
- "For the remaining phases go."
- First real booking, from my phone. Meet link and invitation arrive.
- Moved in Google Calendar, then rescheduled from the mail link: both sync.
- Last deploy of the run.
The 5 h 54 min include the design. They do not include what followed: reviews ran until Sunday afternoon while I slept for part of it. My hands were needed for 6 things an agent should not do: accepting Google's terms, creating a database key, clicking Connect, upgrading the Cloudflare plan, setting up an uptime monitor and making the first booking.
The result: 70 source files, 7,733 lines, 9 database migrations, 473 unit tests and 4 runtime dependencies.
02What the checks found that the tests did not
Every phase ended with a separate agent that got the code and the spec, never the builder's reasoning, and looked for what was missing or broken. 14 of them over the run: plan reviews, break tests, 3 security testers with about 175 live requests, an accessibility audit, and a requirements review that matched 46 requirements from my spec and decisions to the code. On top came an audit of the code against the known bugs of Calendly and cal.com.
| What could have gone wrong | Caught by |
|---|---|
| I drag a booked event to a new time in Google Calendar, and that new time is still offered to other visitors: a double booking. | Requirements review |
| A guest declines the invitation, the booking says declined, but the slot stays blocked. | Requirements review |
| A Meet or mail hiccup after a booking also drops the webhook, so the lead never reaches the CRM. | Audit against Calendly and cal.com bugs |
| A webhook that fails 20 times switches itself off without telling anyone. | Audit against Calendly and cal.com bugs |
| A forged booking request makes the app fetch fresh calendar data from Google before the bot check runs. | Security testers |
| A Gmail timeout makes the retry job send the confirmation twice. | Break test of the new features |
All 6 had passed the build's own tests. All 6 fixes are deployed; only the bot-check fix has been re-tested live so far, the decline fix waits for a real decline. Every checker is a Claude model checking code a Claude model wrote; a human tester would find other things.
Tests check what the builder thought of. A checker with the spec asks what the builder forgot. My spec said a declined invitation must free the slot. The code marked the booking declined and left the event in my calendar. Every test passed, because no test knew that sentence.
2 people grabbing the same slot at the same second is blocked in the database itself: 1 lock, plus a rule that 2 active bookings cannot overlap, buffers included. The sequence was proven step by step against the live functions, in a test transaction that left no rows behind. A truly parallel run is still open. For comparison, cal.com has an issue opened in January 2024 and still open where parallel requests create several bookings for the same time.
03What my own Calendly does now
Everything below is deployed on book.crmmeister.com, built in the same run.
Booking page
- 2 meeting types, 30 and 60 minutes, each on its own page, and link-only types when I need them
- Only days with room, and a "next free" chip
- Visitor's time zone detected, and changeable
- English and German
- Up to 10 guests per booking
- Up to 5 custom questions per type: text, choice, phone, consent
- Name and e-mail prefilled from the link
Calendar conflicts
- Busy times read live from Google; a time that could not be checked is never shown
- Any calendar of the main account that I tick counts, also one added by ID
- Up to 5 more Google accounts, read only for busy times
- All-day events marked Busy block the day
- Buffers, minimum notice, booking window, daily caps
- Double bookings refused by the database
Google sync
- Event with a Meet link, invitation from my own address
- The visitor's notes and the manage link in the event
- I move or delete the event in Google: the booking follows
- A guest declines: the slot frees up
For the visitor
- Reschedule or cancel from the mail link; the same Google event moves
- Confirmation, reminders 24 h and 1 h before, an optional follow-up after the call
- Every app mail in the language they booked in
Webhooks and tracking
- Events: booked, rescheduled, cancelled, attended or no-show, health
- Signed, retried, with a test send, a payload view and replay
- Lead source: UTM, ad click ids from Google, Meta, Microsoft, LinkedIn and TikTok, referrer
- Inline and popup embed for any site I allow, with events for the host page
Admin
- Dashboard: today, health, pause booking, guests off, take a day off
- Bookings in tabs, with search, filters and CSV export
- Reschedule to any time, attended or no-show, private notes, resend, bulk cancel, erase personal data
- Visual weekly hours, date overrides, and a slot checker that says why a time is not offered
- Mail preview and test send in both languages
- Sign-in with Google or an e-mail code
Protection
- Bot check, a hidden trap field, limits per address, IP and hour
- An extra e-mail code step for visitors, switched on by itself when the hourly limit trips
- Health check, uptime monitor, alert mails
- Personal data anonymised after 12 months
Not yet seen live: a reminder or follow-up going out, a webhook reaching a CRM, a deletion or a decline made in Google, the visitor code step, a linked second Google account and the embed on another site.
04Should you build your own Calendly?
| Option | Price | Notes |
|---|---|---|
| Calendly Free | 0 | 1 event type, no webhooks, Calendly branding stays |
| Calendly Standard | 12 USD a month per seat, 10 billed yearly | Adds webhooks and removes the branding; paid per seat |
| cal.com Free | 0 | Unlimited event types for 1 user; the branding stays |
| My own build | About 5 USD a month | A night of building, and the upkeep is yours |
Vendor prices from their pricing pages, fetched 18 October 2026. My 5 USD is Cloudflare's paid Workers plan, which covers every Worker on the account; the database runs on Supabase's free plan. Google Workspace and the Claude Code subscription the build ran on are not counted.
Building did not save money. A booking request used 22 ms of CPU time, more than the 10 ms the free Cloudflare plan allows per request, so I moved to the paid plan before clients got the link. What I got is control: my design, invitations from my address, the data in my database, webhooks into my CRM.
The plan had to route around 3 traps from the docs: Google tokens issued to an external app in "Testing" mode die after 7 days, a free Supabase project pauses after a week without traffic, and Cloudflare Pages has no scheduled jobs, so reminders need a Worker.
Build it if you want that control and will own the boring parts: an uptime monitor, mail authentication, a privacy text, backups, and a review after every change. Take Calendly or the cal.com free plan if you just need a link that works. Self-hosting Cal.diy, the open source edition of cal.com, looks like the middle path, but its own readme recommends it for personal, non-production use. Either way, the 6 failures above are worth testing in any booking setup, bought or built.
The page in the screenshots is live.
If you want to talk about your booking or CRM setup, use it.
Pick a time