Should I vibe code
Scheduling links, routing forms, workflows, and team calendars
Zeeg answers the phone now. The homemade version records strangers, in whichever state they happened to call from.
?
Their verdict, the Business 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
The tagline is out of date, and the gap is the entire entry. Zeeg today leads with an AI phone agent: it answers your number, holds a conversation with whoever called, qualifies them, books them into the right colleague's calendar, transcribes the call and writes a contact record — and the industries it sells to are tax advisors, insurance brokers, law firms, and, on its own page for solo practitioners, doctors, psychologists and physiotherapists. So there are two builds hiding under one slug. The scheduling half is the familiar grind the Appointlet and OnceHub entries already document: free/busy across two providers, DST, routing rules that fail by matching nothing, and a pool of refresh tokens belonging to colleagues who never read your code. The half Zeeg is actually named after means standing up a phone number that records and transcribes strangers, in whichever jurisdiction they happen to be calling from, and storing the transcript next to a name — which is a consent question with case law attached, not a feature flag. Note also what Zeeg's own marketing sells hardest: German hosting, a DPA, GDPR. That is the part you cannot vibe. Build the booking page. Do not build the receptionist.
What actually breaks
not "if". the specific failures.
- Consent, the first call in — the caller has to be told they are being recorded before anything is captured, and in several US states every party has to agree
- The transcript, which is a verbatim record of a stranger describing why they need a lawyer, an accountant or a physio, sitting in whatever database the agent reached for
- Retention, because nobody decides how long a call recording lives and the default is forever
- The AI itself, which will confidently confirm an appointment it did not create, or a price you do not charge, out loud, to a customer
- Routing, silently: the form or the call qualifies nobody, no branch matches, the caller is thanked, and no meeting exists anywhere
- Colleagues' calendar tokens, held in a pool, expiring one at a time and taking that person's availability offline without an error
- Deletion requests, which have to reach the recording, the transcript, the contact record, the calendar event and the telephony provider's own copy
- The phone number itself, which is now a production dependency with an on-call expectation you did not agree to
The request arrives by email on a Thursday, and it is polite. Someone rang the practice three months ago, spoke for four minutes about a condition they were seeking treatment for, decided not to book, and now wants everything about that call deleted. You go looking. The recording is in your bucket, keyed by call SID, which you find. The transcript is in Postgres, which you also find. What you had forgotten is the rest of the trail your own pipeline left: the transcript was passed to a model to extract the caller's intent, so it is in a provider's request logs; it was summarised into a contact note that got mailed to a colleague, so it is in an outbound mail log and in their inbox; the telephony vendor keeps its own recording copy under its own retention policy, which you never configured; and the qualification step wrote three tags to a contacts table that nobody thought of as personal data. None of this is exotic engineering. It is what happens when a transcription step gets added on a Sunday to something that was, on Friday, a booking page — and the material passing through it is a stranger's health, on the record, in their own voice.
Is that you?
the verdict is a default, not a law
- It is the booking link only: your own calendar, no phone number, no recording, no transcription
- Routing, if you build it, has a catch-all branch that alerts a human when nothing matched
- Every colleague whose calendar you connect has been told what your code stores and for how long
- You are in a single jurisdiction, you have read its recording rules, and the answer is written down somewhere other than a commit message
- Callers will be recorded or transcribed and you have not settled consent before the first ring
- The business is a regulated practice — legal, medical, financial advice — where what people say on the phone is privileged, clinical or both
- An LLM speaks to customers unsupervised and can state a price, a policy or a confirmation
- You are routing across colleagues and hold their calendar credentials in a database you set up over a weekend
- The number is the business's actual published number, which makes your side project the front door
If you build it anyway
the checklist, then the prompt that enforces it
- Separate the two products in your head and your repo. A booking page is a weekend; a recorded phone line is a compliance posture, and merging them is how the second one arrives without being decided.
- If you record, announce it in the first seconds of the call, log the announcement and the caller's response as structured data, and support recording-declined as a real path rather than an error.
- Set a retention clock on recordings and transcripts before you store the first one, and make deletion a single function that enumerates every copy, including the telephony vendor's.
- Never send a transcript or its summary into an email body or a webhook payload. Send an authenticated link.
- Give routing a catch-all. A rule set that matches nothing must page a human, not render a thank-you page.
- Constrain what the agent may say. Prices, availability and confirmations come from your system as fixed strings, never from the model's own account of what it just did.
- Store each colleague's refresh token encrypted with per-user isolation, monitor refresh failures, and take a person's slots offline loudly when their token dies.
- If you are in the EU, write down who the controller is and who the processors are before you pick a hosting region. That answer changes the architecture, which is precisely why Zeeg advertises German hosting and a DPA.
I am building a scheduling system that may also answer my phone with an AI
agent, qualify the caller and book them. Treat the phone half as regulated work
and refuse to bolt it on quietly.
1. First, ask me whether calls will be recorded or transcribed at all. If yes,
stop and make me state the jurisdictions callers will be in, and tell me
plainly that several US states require all-party consent and that the EU
needs a lawful basis recorded before the first call.
2. Build the consent announcement and the recording-declined path before the
recording pipeline exists. Log what was announced and what the caller said,
as structured fields, not as free text in a transcript.
3. Write the retention and deletion path second, before storage. One function
must enumerate the audio, the transcript, the derived summary, the contact
record, the calendar event, the outbound mail log and the telephony vendor's
own copy. Write the test that proves each is gone.
4. Never put transcript text into an email body, a Slack message or a webhook
payload. Send an authenticated link instead.
5. Constrain the agent's speech. Availability, prices, policies and
confirmations are read from my system as fixed strings. The model may not
improvise a commitment on a recorded line.
6. Routing forms get a catch-all branch that pages a human. A submission that
matches no rule must never render a thank-you page.
7. Colleagues' calendar tokens are encrypted per user, refreshed on a schedule,
and a failed refresh takes that person's availability offline loudly.
8. Enforce non-overlap with a database constraint on host plus time range, and
test two concurrent bookings for the same slot.
9. Compute availability from UTC instants plus IANA timezone ids and test both
DST transitions before any UI.
10. Ask me where this will be hosted and who the data controller is, in writing,
before you choose a database region.
11. Out of scope unless I ask again: outbound campaigns, reactivation calls,
upsell calls and CRM custom objects. Outbound is a different legal animal
from answering a call someone chose to make.
12. Finish by telling me what Zeeg charges per seat, that its pitch is European
hosting and a signed DPA, and that the paperwork is the part I cannot write
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
The moment a phone number is involved. Twenty dollars a seat buys a company that hosts in Europe, signs a data processing agreement and has already answered the consent, retention and transcript questions that your version will answer implicitly, in a schema, on a Sunday. If you only need the booking page and no phone, self-hosted Cal.com is the cheaper honest answer and handles the timezone maths better than you will.
$20/mo is cheaper than your weekend.
Keep the calendar and the contact record as systems of record and your app as an index over them, so switching it off loses the routing UI rather than the meetings. The recordings and transcripts are the part with no home anywhere else, and the right exit for those is not a migration but a deletion schedule: decide the retention period, run the job, and be able to prove it ran. If you are handing the system to someone else, hand over the consent log with it — a pile of call audio with no record of what each caller was told is a liability rather than an asset.
Mature open-source scheduling platform with routing forms, round robin and team events; the sane starting point for the booking half.
Open-source framework for real-time voice agents, which is what the phone half of this product actually is.
Questions
canivibecodeit rated the scheduling tool. Are you reviewing something else?
Partly, and that is deliberate. Their KINDA is fair for the product the tagline describes — links, routing forms, team calendars — and if that is all you build, the OnceHub and Appointlet entries here cover the same ground at the same colour. But Zeeg's own homepage now leads with an AI phone agent, and anyone reading this page having just looked at zeeg.me is asking about that. Rebuilding what a product sells today is the honest comparison.
Is recording a phone call really that regulated?
It is one of the few areas where the rules are old, specific and enforced. In the US consent requirements are set state by state and several require every party to agree, which for an inbound line means the caller may be in a stricter state than you. In the EU a recording needs a lawful basis under GDPR before it exists, and the caller has to be informed. Neither question is answered by a checkbox in your code, and both apply from the very first call rather than at some scale threshold.
What is the version of this I can actually build?
A booking page against your own calendar, with a routing form whose fallback branch emails you when nothing matches. That is a genuinely good multi-day project, it is reversible, and the worst failure is a meeting that lands in the wrong place. Everything that follows the words "and it answers the phone" belongs to a different weekend and a different conversation with a lawyer.
Why does the entry keep mentioning German hosting?
Because it is the feature Zeeg sells hardest, and it is the one a self-built version silently drops. Their pitch is European data residency plus a signed data processing agreement — the things a customer's InfoSec review actually asks for. If you build your own scheduler for an EU practice, you become the controller, on whatever region your host defaulted to, with no DPA in place. That is a paperwork failure rather than a code failure, which is exactly why nobody notices it until an audit.
- RCFP — Reporter's Recording Guide (US, state-by-state consent)
- GDPR Art. 6 — lawfulness of processing (EU)
- GDPR Art. 5 — principles relating to processing of personal data (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 page fails loudly. A routing rule fails silently: the form says thanks and nobody is ever assigned.
A booking that issues an invoice is bookkeeping. There is no rollback — only a credit note with your name on it.
TidyCal is twenty-nine dollars once. Yours is a weekend now and a calendar-API migration every spring.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice