A scheduling product can look familiar while its reuse boundary changes substantially. In an April 2026 engineering explanation, Cal.com described moving its production code to a private repository and separating the public, self-hostable Cal.diy project. The current Cal.diy repository license is MIT. That distinction matters to a builder choosing a foundation: a permissive license and a complete match for the intended customer workflow are separate findings.
Start with the workflow you intend to sell
The engineering post identifies capabilities removed from the community product, including team and organization features, routing forms, and automated workflows. It describes the remaining scheduling and booking infrastructure. Treat that list as a dated change record and retest the current revision; it is not a complete October feature audit. A founder should turn that information into a requirements sheet before producing a sales page. Record the exact repository, revision, required behavior, and evidence for each feature. An old comparison article or a remembered screenshot is weak evidence for a current implementation.
Consider a hypothetical appointment helper for independent consultants. Its initial job might be letting one person offer available times, accept a booking, reschedule, and cancel. A clinic’s pooled availability and routing requirements describe a different product. Writing both audiences into the same early roadmap can conceal a missing capability until a customer depends on it.
Run a booking lifecycle trial
- Create a disposable test calendar and a separate application identity. Use fictional appointments rather than a live client schedule.
- Write expected outcomes for booking, timezone changes, cancellation, and a disconnected calendar. Keep the expectation beside the observed result.
- Ask another person to complete the flow on a phone without spoken instructions. Record where they need help and whether cancellation reaches the correct calendar.
- Pin the version that passed and repeat the critical flow after an update. A green build alone does not confirm that the calendar integration still works.
This trial produces a bounded compatibility record. It does not establish demand, reliable delivery at scale, or an entitlement to every feature available in the commercial service. Keep those questions open until each has its own evidence.
Choose a maintenance promise you can keep
MIT permits broad reuse under its stated conditions, including retaining the required notice. An operator still needs a plan for updates, backup, calendar-provider changes, and incident handling. When a prospective customer asks for a team workflow absent from the selected project, record the gap explicitly. Compare an appropriate licensed product, a narrowly scoped integration, and declining that requirement before estimating custom development.
Also separate the software budget from dependency access. Calendar credentials, mail delivery, and a public callback URL belong to the actual deployment. A local trial should not silently gain permission to send invitations, connect a client account, or start billing. List who owns each account and what happens when that relationship ends.
Use a concrete stop condition
Pause the offer if the promised booking lifecycle fails, the required feature exists only in another edition, or no one can explain the recovery process. Continue when the narrow job works and the operating responsibility is clear. The useful lesson from Cal.diy is a habit of checking product identity and capability together. This study draws no conclusion about Cal.com’s revenue, conversion rate, or the commercial prospects of a new scheduling service.