Appointment booking
An example app for service bookings with availability, time zones, capacity limits, payments, and waitlists.
Example app Built from planned modules. Not a customer. Not a supported app today.
Illustrative rule: class capacity with a waitlist
| 1 | modules: | |
| 2 | +Added | data: |
| 3 | +Added | sessions: |
| 4 | +Added | fields: |
| 5 | +Added | starts_at: timestamp |
| 6 | +Added | capacity: integer |
| 7 | +Added | rules: |
| 8 | +Added | reserve_spot: |
| 9 | +Added | on: reservation.requested |
| 10 | +Added | if: reserved < capacity |
| 11 | +Added | else: join_waitlist |
| 12 | +Added | cancel_window: |
| 13 | +Added | before_start: 24h |
| 14 | +Added | refund: full |
Placeholder values and unfinished syntax. Not a released feature.
What is the Appointment booking example app?
A client browses open times for a trainer, a salon, or a class and reserves one. If the session is full, they join a waitlist. They pay or hold the spot, and they can cancel under rules the provider sets. Reminders arrive before the appointment.
This category is a design target. It is not a claim that Edict already supports a complete booking app.
What backend does the Appointment booking example need?
- Availability.
- Time zones.
- Capacity constraints.
- Reservations.
- Payments.
- Cancellation rules.
- Waitlists.
- Notifications.
How do the planned modules compose in the Appointment booking example?
Booking is a good test of correctness. Two clients may ask for the last spot at the same moment, so the capacity check and the reservation must happen as one atomic step. The database and Business logic are designed to do that together, with the rule stated once. Time zones are designed to be stored with each session so that a reminder lands at the right local time.
Payments and credits are designed to take payment where the platform rules allow it, and to apply refund-aware accounting when a client cancels within the allowed window. When a spot opens, Business logic is designed to move the first person on the waitlist forward and emit an event, and Push notifications to tell them. Background jobs are planned to send reminders on schedule.
What would an illustrative rule look like in the Appointment booking example?
The configuration above reserves a spot when there is room, otherwise adds the client to a waitlist, and sets a cancellation window with a refund. The key names, the window, and the syntax are placeholders and are not final.
What is example and what is planned in the Appointment booking example?
All modules named here are planned and in development. Real payment integrations are not available. Your business owns the cancellation policy, the price of each service, and compliance with payment and consumer rules. Whether a booking should be paid in the app depends on what is sold and on store policy, which your app must check.
See the Business logic and Payments and credits module pages for the planned design. Join the beta waitlist to follow progress.
Which examples are similar to Appointment booking?
These share the most modules with this one.
Get an invitation when the beta opens.
Joining gets you email updates while Edict is built, and an invitation to the hosted beta when it opens.
Building now. No launch date yet.
Join the beta waitlist
Open the signup form on KitEdict is in development. Joining does not create an account or start a trial.