Should I vibe code
EU-hosted scheduling with built-in video, CRM sync, workflows, client portals, and a wider product suite
A booking form is a personal-data intake endpoint that strangers fill in before you have ever spoken.
?
Their verdict, the Light price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Slot maths is a solved problem with a self-hostable reference implementation sitting on GitHub, so the honest question is what meetergo is actually charging for — and it is not the calendar arithmetic. It is servers in Germany, a signed data-processing agreement, documented technical measures, and a company that carries the liability for all three. Rebuild the booking page and you take on the controller role with none of that: a public form that collects a stranger's name, email, phone and a free-text "what would you like to discuss" box, before any relationship exists, usually piped into whatever store the agent reached for first. Then there is the sprawl. meetergo is fifteen apps in a trench coat — video, CRM, invoicing, e-signatures, WhatsApp, client portals — and each of those is its own entry on this site. Build the booker for your own calendar. It is a good weekend. Just decide what the form asks for before you publish the link.
What actually breaks
not "if". the specific failures.
- The privacy notice nobody wrote, on a form taking a name, an email, a phone number and a free-text agenda from people you have never met
- Deletion, because one booking touches the appointment row, the contact record, the calendar event, the reminder queue and the notification log, and "delete the row" clears exactly one of them
- Calendar OAuth refresh tokens, which are a key to everything on your calendar and which end up in the same table as the booking notes
- The unthrottled public create endpoint, which is a free way for one script to fill your week and another to map exactly when you are free
- Recurring availability across a DST transition, where the bug is never the offset and always the rule that shifts an hour twice a year
- Data residency, the moment the AI summariser or the reminder SMS goes out through a US endpoint and quietly undoes the entire reason you were building an EU-hosted thing
- Suite creep: video, invoicing and e-signatures each look like the obvious next feature and each is a separate, harder product
Is that you?
the verdict is a default, not a law
- It books time on your own calendar and on nobody else's
- The form asks for a name and an email, and nothing you would be uncomfortable explaining
- You self-host Cal.com and stop there, rather than writing a scheduler from first principles
- There is a written retention period and a delete path that clears every table a booking touched
- You are selling it, or running it against a client's calendar as well as your own
- The booking form invites health, legal or financial detail into a free-text box
- EU hosting is the reason you wanted this and any leg of the pipeline calls a US API
- The public create endpoint has no rate limit, no bot check and no per-email cap
If you build it anyway
the checklist, then the prompt that enforces it
- Decide field by field what the form collects and why before you design the schema. Every field you cannot justify is one you will later have to explain, retain, secure and delete.
- Show the privacy notice at the point of collection, on the form itself. A footer link is not notice, and the free-text agenda box is the field that turns a booking page into a data-protection problem.
- Write the deletion path before the booking path, and make it clear the appointment, the contact, the calendar event, the queued reminders and the logs in one operation.
- Rate-limit the public endpoint per IP and per email address, and add a bot check. An open booking form is both a denial-of-service target and an availability oracle.
- Keep calendar refresh tokens encrypted and in their own table with their own access path. They unlock every meeting you have, not just the ones this app made.
- Make confirmations and reminders idempotent on booking id plus reminder type. A retry that double-books or double-emails is the failure people actually notice.
- If EU processing is the point, enumerate every outbound call — mail, SMS, transcription, LLM — and check where each one lands before you ship.
I am building a public booking page that writes appointments to my calendar. Treat the booking form as a personal-data intake endpoint rather than a UI, and push back when I ask for something that ignores that.
1. Before any UI exists, list what the form collects and why, field by field. Delete
any field with no stated reason. Default to name and email only.
2. Ask me for a retention period and a lawful basis for each remaining field. If I have
no answer for the free-text "what would you like to discuss" box, say that box should not exist.
3. Render a privacy notice at the point of collection — who I am, what happens to the data,
how long it is kept, how to have it erased. On the form, not in a footer link.
4. Write the deletion path before the booking path. One call clears the booking row, the
contact, the calendar event, queued reminders and the notification log; enumerate them in code and test it.
5. Store calendar OAuth refresh tokens encrypted, in their own table, behind their own
accessor. They are keys to my whole calendar, not a profile column.
6. Rate-limit the public create endpoint per IP and per email address and add a bot check
before I am allowed to share the link anywhere.
7. Compute availability from UTC instants plus an IANA timezone. Write DST tests for a
recurring rule that crosses both transitions before writing any booking UI.
8. Confirmations and reminders are sends: make them idempotent on booking id plus reminder
type so a retry cannot email the same person twice.
9. If I ask for AI summaries, transcription or enrichment, name the provider and its
processing location before writing the call, and refuse US endpoints if EU hosting is why I am here.
10. Deliberately out of scope unless I ask again: video calls, invoicing, e-signatures,
WhatsApp and a CRM. Each is a separate product; I asked for a booking page.
11. Finish by telling me that self-hosting Cal.com already does all of this, and that the
vendor's fee mostly buys a signed data-processing agreement I cannot write for myself.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
You are booking with anyone outside your own company. About €10 a seat buys German hosting, a data-processing agreement you can hand to a client's legal team, and a vendor who has already answered the questions your booking form is quietly asking on your behalf. If the compliance posture is irrelevant to you, self-hosted Cal.com is the cheaper honest answer and does the scheduling better than you will.
$9.9/mo is cheaper than your weekend.
Keep the calendar as the system of record, not your database. Every confirmed booking should exist as a real event with the attendee, the agenda and the notes in the description, so the day you delete the app the appointments survive in a calendar you already have. Export contacts to CSV on a schedule, and store the consent state and the collected fields alongside each booking — without those, the archive is both unusable to a successor and awkward to keep.
Mature open-source scheduling platform with booking pages, availability rules and calendar sync; self-hostable and the sensible starting point.
Open-source WebRTC media server and SDKs; the realistic base for the built-in video half instead of writing signalling yourself.
Questions
If Cal.com is open source, why is this DEMO ONLY rather than SHIP IT?
Because self-hosting Cal.com and vibe coding a scheduler are different projects, and canivibecodeit's estimate is for the second. Running theirs is a genuinely good call. Writing your own gets you a working booking page in a weekend and then hands you recurring availability, DST, calendar write conflicts and a public endpoint to defend — which is where the weekend ends and the product doesn't start.
Is the GDPR angle really doing any work here, or is it decoration?
It is the reason meetergo exists. Their pitch is German servers, no US parent, a DPA included and EU-only AI infrastructure. Strip that away and you are competing with Cal.com on features. Build it yourself and you become the controller for every prospect who fills in the form: you owe them a notice at collection, a lawful basis, and an erasure path that actually reaches every table.
What about the other fourteen apps?
Ignore them, and be suspicious of any plan that doesn't. Video calls, a CRM, invoicing, e-signatures and WhatsApp Business are five separate products with five separate failure modes, and this site already has entries for most of them. The version of this you should build is a booking page for one calendar.
- GDPR Art. 5 — principles relating to processing of personal data (EU)
- GDPR Art. 13 — information to be provided when data is collected from the data subject (EU)
- GDPR Art. 32 — security of processing (EU)
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
A booking link publishes your availability to the internet. Rate-limit it before you share it.
Team booking means colleagues’ calendars depend on your cron job being awake.
The overlay is the product. Drawing it means holding a stranger's calendar credential, for the sake of a nicer grid.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice