A booking service built around your rules.

Set your availability, decide who can book, and choose how people reach you. Build on reusable scheduling and calendar functions, then make the rules and interface yours.

Separate the reusable logic from the personal choices.

01

Availability

Calculate candidate times from a window and supplied busy intervals.

02

Booking rules

Decide which requests may be accepted, refused, or changed.

03

Conflict checks

Test whether a requested time collides with existing events.

04

Calendar action

Read or write within the host permissions the owner approved.

05

Contact channel

Receive the proposal by email, messenger, platform, your own site, or Beacon.

The last part is transport. A verified booking rule does not depend on Beacon. Email can carry an invitation and a person can accept or decline it later; a connected agent can answer sooner. Beacon explores one shared point that could receive a proposal while the owner is offline.

The same job, a different way to own it.

Calendly today

A complete hosted scheduler.

Booking links, connected calendars, availability rules, reminders, and team scenarios are supplied as a service. You use its product and integration model.

The Kraton direction

Your own assembled service.

Reuse and verify the underlying functions, keep your rules and state in your app, and choose how people reach it. The current demos are pieces of this service, not feature parity with Calendly.

Try the working parts. Help shape what comes next.

Runnable parts

  • A pure typed scheduler computes candidate times from supplied busy intervals without reading a calendar.
  • The booking composite implements domain operations behind a typed calendar adapter; local fixtures and a supported macOS calendar path exist.
  • Companion can expose a host-bounded Calendar.app action to a connected assistant on a supported Mac.

Work to fund and establish

  • A complete public booking experience and its chosen contact channel.
  • Precise conflict and state-transition contracts, including time zones, concurrent requests, rescheduling, and external write failures.
  • Independent attacks and, where suitable, machine-checked proofs of named properties tied to the executable version.

Fund the property you need to rely on.

The founding calendar order is open for a precise specification, adversarial verification, and proposals for formal proof. Its budget and bids are shown as they actually stand.

Open calendar order