Should we build our own Acuity-class platform?

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.

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.

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.

Stripe plus HitPay is a sensible payment split

HitPay is a plausible second rail for WhatsApp and staff-assisted bookings. Its API can create a payment request with an amount, currency, allowed methods, expiry, customer details, an internal reference, metadata, and a checkout URL. HitPay documents redirect checkout, drop-in UI, payment links, QR methods, cards, and local payment methods that vary by merchant country.

The backend should expose one payment interface with Stripe and HitPay adapters. Store the provider, provider payment/request ID, booking intent ID, order ID, currency, amount, status, and refund state. HitPay says to confirm payment from its signed webhook rather than the redirect, and its newer dashboard webhook system supports payment_request.completed. The per-request webhook field is documented as deprecated.

Recommended wrapper flow

1. Create a local booking intent with an expiry and price snapshot.
2. Check Acuity availability and validate forms, certificates, and add-ons.
3. Create a Stripe Checkout Session or PaymentIntent with the booking intent ID in metadata.
4. Use the Stripe webhook as payment confirmation, not the browser return URL.
5. Re-check availability, then create the appointment through Acuity’s public client-style endpoint so availability and forms are validated.
6. Link the Acuity appointment ID to the local order and show the local Stripe state on the Nowhere dashboard.
7. 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

What “all of Acuity” includes

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.

Open-source candidates

Feature-fit matrix

Directional comparison based on official documentation reviewed 2026-08-13. “Strong” means the project documents the capability in its own domain, not that it matches Acuity’s exact behavior.

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.

1. 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.
2. Separate the domains. Model catalog, capacity, booking, commerce, entitlements, and integrations as explicit boundaries.
3. Migrate one product family. Use Credit Pack and 10-Pass Pack as the first owned slice because their business rules already exist in Nowhere.
4. Run Acuity in parallel. Import and reconcile orders, certificates, appointments, clients, and balances before changing the source of truth.
5. Add higher parity later. Subscriptions, gift certificates, classes, waitlists, mobile admin, advanced reports, and multi-processor support should follow proven ledger and capacity behavior.

Sources

1. Acuity feature overview — scheduling, clients, payments, packages, subscriptions, add-ons, sync, and reporting.
2. Acuity create appointments API, appointment update API, appointment payments API, and availability check API.
3. Acuity appointment payment status and accepting payments.
4. Acuity client booking flow and add-another-time behavior.
5. Squarespace acceptable-use policy and developer policy — reverse-engineering and supported-interface restrictions.
6. HitPay online payments, payment request API, and webhooks and signature verification.
7. HitPay API overview, payment links, Australia onboarding, and published pricing examples.
8. Acuity packages, gift certificates, and subscriptions.
9. Acuity payment choices and payment processors.
10. Acuity intake forms and agreements, resources, and reports.
11. Easy!Appointments features, REST API, and GPLv3 repository.
12. Cal.com documentation, event type API, Stripe payments, webhooks, and license explanation.
13. LibreBooking repository and payment/resource documentation.
14. ERPNext repository, appointments, payment requests, and subscriptions.
15. Saleor repository, Saleor documentation, Medusa documentation, and Medusa MIT repository.