The demo is twenty minutes because one sentence on the site is not gated on the scheduler
Decided
The Cal.com event type published at cal.com/novelsystems/demo is 20 minutes, not 15 and not 30. No code changed to accommodate it.
Why this needed deciding at all. The site did not agree with itself about how long a demo is. The hero said "Book a 20-minute demo", PRIMARY_CTA.label said "Book Enterprise Demo", the chat widget said "Thirty minutes with a solutions engineer", and the fallback booking modal offered thirty-minute slots and emailed "Duration: 30 minutes". That contradiction is L12 in docs/legal/FLAGGED-CLAIMS.md, and D-015 had already narrowed it from a functional defect to a copy defect. Publishing an event type forces the question, because whatever length the vendor's dashboard holds is the length a stranger sees one click into the funnel.
The rule the codebase already applies. Three files carry the same policy in their comments and their branches: *once a scheduler is live, no copy names a duration.* components/ui/booking-modal.tsx:950-955 states the reasoning most directly — a scheduling page defines its own event length in the vendor's dashboard, this deployment cannot read it, and "a CTA promising '20 minutes' over an event booked for 45 is a small lie told at the exact moment a stranger decides to trust us." So BookDemoTrigger falls back to "Book a demo". app/page.tsx:96 applies the same rule to the hero label. components/ui/live-chat.tsx:152-160 drops "Thirty minutes" from the scheduler reply.
If that rule were the whole story, any event length would have been defensible and this entry would not exist.
The one string outside the rule. app/platform/cpq/page.tsx:690 reads: "We will run them through the engine on the call and put the cut list next to whatever your current process produced. Twenty minutes, no slides." It is prose in the middle of a section, not a CTA label, and nothing makes it conditional on schedulingLink(). Setting the event to 30 minutes would have made that sentence false on a live page the moment the scheduler went up — a *new* false claim created by an action taken to close a task, which is the worst kind.
The alternative considered. Gate that sentence on scheduler state too, and then pick any length. Rejected: it rewrites live marketing copy to accommodate a calendar setting, when setting the calendar to 20 minutes costs nothing and makes every existing sentence true at once. It would also have widened the blast radius of a task that needed no code change at all. The general rule — make the world match the claim when that is cheap, and edit the claim only when it cannot be — favours 20.
Secondary effect, which was a bonus rather than a reason. Twenty also satisfies the acceptance language already written into docs/PRD-STATUS.md, docs/FINAL-REPORT.md and docs/recon-12-13-16.md, all of which specified a 20-minute event type. Those were written from the same reading of the CPQ page, so this is one fact agreeing with itself rather than three sources corroborating.
What would make this wrong. A demo that genuinely cannot be run in twenty minutes. If the first three real bookings overrun, the honest fix is to change the event type *and* the CPQ sentence together, in that order, rather than leave a 20-minute promise attached to a forty-minute call. The sentence is the constraint, not the calendar.