Skip to content
Ascend GTM Ops — Docs

Smart Scheduler Phases 2-5 Formally Deferred

ADR-019 — Smart Scheduler Phases 2-5 Formally Deferred

Status: Accepted Date: 2026-04-23 Deciders: Mishaal Murawala Relates to: ADR-018 (Phase 1 sign-off, precondition 2), docs/prd/smart-scheduler-v5-implementation.md, ADR-014 (Cal.com phases deferred — this ADR supersedes-in-part)

Context

Smart Scheduler v5 (PR #25, merged 2026-04-14) shipped Phase 1: Cal.com self-hosted integration + SES outbound. The PRD had Phases 2-5 queued:

  • Phase 2: findMeetingTimes strategy router across Google + Microsoft calendars
  • Phase 3: multi-calendar workflow orchestration (delegation, group scheduling)
  • Phase 4: recurring scheduling intelligence (pattern-learning, auto-rebook)
  • Phase 5: partner-facing booking widgets and embed surfaces

None of Phases 2-5 have active client demand. Kahuna uses Phase 1 for external booking only. Point Field Partners has shown no scheduling need beyond Phase 1. The PRD was written against a 2-tenant growth scenario that hasn’t materialized.

ADR-014 had already deferred Cal.com phases; this ADR extends that to all Scheduler phases 2-5 and formalizes the condition for revisiting.

Decision

Phases 2-5 of docs/prd/smart-scheduler-v5-implementation.md are formally deferred with no target date.

Deferred means:

  • The phases are not in the backlog. They do not get groomed, sized, or carried as open work.
  • The PRD stays in-tree at docs/prd/smart-scheduler-v5-implementation.md as reference.
  • This ADR is the ledger entry. LEDGER is updated accordingly.

Reversal criteria — ANY one of the following re-opens Phase 2+:

  1. Paying client asks by name for functionality described in Phase 2, 3, 4, or 5. “Paying” = contracted PFP portfolio company or Kahuna expansion with explicit scheduling ask.
  2. Phase 1 usage data shows >50 bookings/week via Cal.com + user-expressed demand for calendar-merge or recurring patterns.
  3. A downstream ADR (e.g., ADR-021+) requires Phase 2 as dependency.

If any one fires, the ADR that triggers the reversal links back here and specifies the scope of phases to revive.

Rationale

  • Opportunity cost is real. Each of Phases 2-3 is 2-4 weeks of engineering work with zero current user. Context-plane work (ADR-016) and platform hardening (ADR-018 Phase 1) have documented demand and a product thesis. Scheduler 2-5 does not.
  • Feature completeness ≠ product-market fit. The PRD was correct about the capability needing to exist eventually; it was speculative about when. Explicit deferral is honest; vague “later” is not.
  • Keeps the tool count down (ADR-018 precondition 4). If Phase 2 shipped today, it adds 3-5 new tools — violating the no-new-tools-during-sprint rule.

Consequences

Positive

  • Clear exit for stalled work. No one has to guess whether Scheduler 2-5 is “active.”
  • LEDGER cleanly shows the deferral.
  • Engineering cycles redirect to Phase 1 consolidation and Phase 2 context plane.

Negative

  • If a client asks for Phase 2 functionality on short notice, we need to cite the reversal criteria and scope a surgical revival — which takes a week just to plan. Mitigation: if a PFP scoping call surfaces a scheduling need, open a discovery ADR immediately rather than waiting.

Neutral

  • ADR-014 is partially superseded. It deferred Cal.com phases specifically; this ADR defers the full Scheduler 2-5 scope.

References

  • PRD: docs/prd/smart-scheduler-v5-implementation.md
  • Phase 1 source: src/handlers/scheduling/*, src/cron/meeting-scheduler.ts
  • Cal.com deployment: Phase 1 live in production.
  • Superseded (partial): ADR-014