Availability correctness
Calendar pooling, buffers, resources, class capacity, global limits, and race conditions at the final booking request.
Owned scheduling + commerce · 13 August 2026
Should we build our own Acuity-class platform?
Yes, but “all of Acuity” is a scheduling, payments, commerce, ledger, communications, and operations programme. There is no single open-source fork that gives us the whole thing.
Bottom line
Build the owned product on the existing Nowhere stack if long-term control is the goal. For a prototype, inspect Easy!Appointments for scheduler ideas, Cal.com for modern scheduling/API patterns, LibreBooking for resources, and Saleor/Medusa or ERPNext for commerce. Do not assume any of them removes the work of building credit packs, appointment capacity, cancellation/refund semantics, and a safe payment/booking ledger.
Can our own widget be better than Acuity?
Yes. We can own the guest experience while Acuity remains the scheduling engine. Its public API exposes appointment types, dates, times, classes, forms, certificates, add-ons, appointment creation, rescheduling, cancellation, and webhooks. That is enough to build a branded flow around the bathhouse journey instead of presenting a generic scheduler.
| Surface | Our opportunity | Difficulty |
|---|---|---|
| Service discovery | Explain the experience, inclusions, restrictions, and best choice before showing times. | Low |
| Availability | Show clearer alternatives and a “choose experience, then time” flow while querying Acuity live. | Medium |
| Cart | Support several compatible sessions, products, add-ons, or pass redemptions in one branded flow. | Medium-high |
| Forms | Use progressive disclosure, better copy, conditional questions, and saved guest details. | Medium |
| Checkout | Use Stripe for a clearer total, package balance, receipt, and product upsell experience. | Medium |
| Confirmation | Combine booking, payment, balance, directions, and next steps into one useful confirmation. | Medium |
The cart is not the hard part. The hard part is making a multi-item cart safe against live availability, payment failure, certificate balance, cancellation/refund rules, and retries. We can build our own cart without Acuity’s private cart endpoints.
Stripe can be our payment truth
The clean architecture is to separate financial truth from scheduling truth. Stripe owns charges and refunds; Nowhere owns the order, payment ledger, entitlement balance, and reconciliation state; Acuity owns appointment availability and the operational calendar.
| System | Source of truth |
|---|---|
| Stripe | Payment intents or Checkout Sessions, charges, refunds, disputes, and processor webhooks. |
| Nowhere D1 | Order, payment transaction, refund, booking intent, package/credit ledger, and dashboard payment status. |
| Acuity | Availability, calendar/resource assignment, appointment record, forms, reminders, and schedule operations. |
Acuity’s public API documents reading appointment payments, but not creating a payment or marking an external Stripe transaction as paid. Its documented appointment update fields include client details, forms, certificates, notes, and labels. Acuity also says invoice payments do not update the appointment record. We can add an “Externally paid” label or payment reference to the appointment, but the native Acuity paid icon is not a supported public integration contract.
Private API verdict: an admin checkout request might be discoverable in a test account and could make Acuity’s native status look right, but it is undocumented, can depend on sessions/CSRF and UI behavior, and may change without notice. Squarespace’s current acceptable-use and developer policies prohibit reverse engineering its services. Treat private requests as a diagnostic experiment or permissioned integration question, never as the foundation of production booking.
Recommended wrapper flow
- Create a local booking intent with an expiry and price snapshot.
- Check Acuity availability and validate forms, certificates, and add-ons.
- Create a Stripe Checkout Session or PaymentIntent with the booking intent ID in metadata.
- Use the Stripe webhook as payment confirmation, not the browser return URL.
- Re-check availability, then create the appointment through Acuity’s public client-style endpoint so availability and forms are validated.
- Link the Acuity appointment ID to the local order and show the local Stripe state on the Nowhere dashboard.
- If payment succeeds but the slot is gone, automatically void/refund the payment and explain what happened.
For multi-appointment carts, use an idempotent finalization worker with compensation logic. Acuity does not document a general-purpose multi-item hold, so the first release should keep carts simple or accept explicit partial-success/refund handling.
What would still be hard to replicate
Payment ordering
Payment can succeed after a slot disappears, or booking can succeed before payment. Both cases need idempotency and compensation.
Entitlements
Certificates and packages change payment status, balances, expiry, cancellation returns, and who owns versus redeems the credit.
Operations
Recurring series, rescheduling, no-shows, reminders, calendar sync, webhook retries, audit history, and staff exceptions.
What “all of Acuity” includes
| Area | Parity we would need to own |
|---|---|
| Services | Appointment types, categories, duration, price, add-ons, padding, locations, and direct booking links. |
| Availability | Calendars, calendar pooling, availability groups, start intervals, advance notice, blocks, daily limits, look-busy and gap rules. |
| Capacity | One-to-one appointments, overlap rules, classes, seats, class series, rooms/resources, and waitlists. |
| Booking flow | Date/time selection, add another time, recurring bookings, quantity/multiple spots, timezones, client accounts, and confirmation. |
| Client data | Profiles, history, forms, agreements, file uploads, internal forms, notes, and labels. |
| Commerce | Full payment, deposits, saved card details, later charges, payment links, invoices, cash, tips, refunds, receipts, and payment status. |
| Products | Packages, gift certificates, subscriptions, booking codes, redemption, balance allocation, and expiry. |
| Growth and operations | Coupons, add-ons, reminders, email/SMS templates, calendar sync, webhooks, reports, exports, permissions, and mobile admin. |
The hard part is the intersection. A package redemption changes payment status and balance. A cancellation may return credit or trigger a refund. A resource can cap capacity across calendars. A recurring booking can multiply add-ons and payment obligations.
Payments and packages are a ledger, not a checkout page
A serious replacement needs explicit state for orders, payment intents, transactions, refunds, appointments, and entitlements. It must handle payment success followed by booking failure, booking success followed by payment failure, retries, disputes, and webhook reconciliation without double-charging or double-booking.
Processor lifecycle
Authorize or collect full payment/deposit, handle processor webhooks, refunds, failed payments, saved methods, receipts, and reconciliation. Never store raw card data.
Credit-pack model
Product → order → certificate/code → immutable balance ledger → redemption tied to an appointment. Cancellations and manual adjustments become auditable events.
Separate store and booking
Guests should be able to buy a credit pack without a time, book with a code, pay for a single appointment, or buy a gift for someone else.
Idempotency and compensation
A browser retry, processor retry, or webhook retry must not create a second appointment or second charge. Partial success needs a documented compensation policy.
Open-source candidates
Easy!Appointments
GPLv3, self-hosted PHP/MySQL. Services, providers, working plans, booking rules, Google/CalDAV sync, group sessions, REST API, and webhooks. Official marketing mentions payments, but public docs do not establish an Acuity-style product/package/certificate/subscription layer.
Verdict: useful scheduler reference or prototype fork; not a complete fit for Nowhere.
Cal.com
Modern React/Next.js-oriented scheduling with event types, custom fields, seats, recurring bookings, limits, buffers, APIs, webhooks, and Stripe payments. The repository documents AGPLv3 core plus commercial enterprise areas.
Verdict: best scheduling/API reference; weak for products, packages, certificates, and a credit ledger.
LibreBooking
GPLv3 resource scheduling with multi-resource booking, waitlists, quotas/credits, reporting, and Stripe/PayPal gateways. PHP/MySQL and oriented around reservations rather than customer commerce.
Verdict: strongest resource-capacity reference; not an Acuity commerce fork.
ERPNext/Frappe
GPLv3 ERP with products, orders, invoices, payment requests, pricing rules, subscriptions, accounting, and commerce. Its appointment feature is a basic lead/employee meeting flow.
Verdict: strong commerce/accounting base; custom scheduling app required.
Saleor or Medusa
Saleor provides API-first products, checkout, promotions, gift cards, customers, orders, and payments. Medusa provides MIT commerce modules for carts, payments, products, promotions, bundles, and subscriptions.
Verdict: useful commerce components; neither supplies appointment capacity or booking rules.
The honest answer
The open-source ecosystem is fragmented by domain. A mature scheduler, a mature commerce engine, and a custom entitlement ledger still need to be integrated and operated together.
Verdict: choose a base for the hardest domain, not by star count.
Feature-fit matrix
| Requirement | Easy | Cal | Libre | ERPNext | Saleor/Medusa | Nowhere |
|---|---|---|---|---|---|---|
| Appointment types/schedules | Strong | Strong | Partial | Partial | None | Build |
| Calendars/providers | Strong | Strong | Strong | Partial | None | Build |
| Classes/seats/recurrence | Partial | Partial | Partial | Weak | None | Build |
| Shared resources | Unclear | Partial | Strong | Partial | None | Build |
| Payments at booking | Unclear | Stripe | Stripe/PayPal | Gateway | Strong | Provider |
| Products/cart | Weak | None | Weak | Strong | Strong | Build/module |
| Packages/credits/certificates | None documented | None documented | Credits | Custom | Gift cards | Domain fit |
| Fit with Next/Cloudflare/D1 | Poor | Better | Poor | Poor | Separate service | Best |
| License simplicity | GPLv3 | AGPL + EE | GPLv3 | GPLv3 | MIT/BSD options | Own code |
Recommendation for Nowhere
Build the owned product on the current Next.js + Cloudflare Workers + D1 foundation if we decide that booking rules, customer experience, product economics, and data ownership are strategic. Do not replace the whole system in one pass.
- Define the cut line. Start with bathhouse sessions, capacity, guest forms, certificate-backed credit packs, Stripe card payments, cancellation/reschedule policy, email/webhooks, staff calendar, and reconciliation.
- Separate the domains. Model catalog, capacity, booking, commerce, entitlements, and integrations as explicit boundaries.
- Migrate one product family. Use Credit Pack and 10-Pass Pack as the first owned slice because their business rules already exist in Nowhere.
- Run Acuity in parallel. Import and reconcile orders, certificates, appointments, clients, and balances before changing the source of truth.
- Add higher parity later. Subscriptions, gift certificates, classes, waitlists, mobile admin, advanced reports, and multi-processor support should follow proven ledger and capacity behavior.
Do not fork on assumption. A short code-level spike against Easy!Appointments and Cal.com can answer whether either actually reduces work. The spike should inspect license boundaries, payment code, data model, availability rules, extension points, deployment cost, and migration path—not just the public demo.
Sources
- Acuity feature overview — scheduling, clients, payments, packages, subscriptions, add-ons, sync, and reporting.
- Acuity create appointments API, appointment update API, appointment payments API, and availability check API.
- Acuity appointment payment status and accepting payments.
- Acuity client booking flow and add-another-time behavior.
- Squarespace acceptable-use policy and developer policy — reverse-engineering and supported-interface restrictions.
- Acuity packages, gift certificates, and subscriptions.
- Acuity payment choices and payment processors.
- Acuity intake forms and agreements, resources, and reports.
- Easy!Appointments features, REST API, and GPLv3 repository.
- Cal.com documentation, event type API, Stripe payments, webhooks, and license explanation.
- LibreBooking repository and payment/resource documentation.
- ERPNext repository, appointments, payment requests, and subscriptions.
- Saleor repository, Saleor documentation, Medusa documentation, and Medusa MIT repository.