Processor lifecycle
Authorize or collect full payment/deposit, handle processor webhooks, refunds, failed payments, saved methods, receipts, and reconciliation. Never store raw card data.
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.
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.
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 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.