Skip to content

Production readiness

Treat this checklist as a release gate before inviting real attendees.

Required before customer data

  • Enable TLS between the application and production MySQL, or use a private authenticated tunnel.
  • Restrict MySQL access to the application server and backup systems.
  • Configure a real email gateway so magic links reach users.
  • Replace the mock payment adapter with a tested MobilePay integration.
  • Keep DEMO_AUTH_ENABLED=false in the real production application. The separately routed demo container may enable it against the dedicated demo database.
  • Use EMAIL_ADAPTER=webhook and PAYMENT_ADAPTER=webhook.
  • Change the administration footer and test-mode messaging to reflect the actual payment environment.
  • Confirm backup retention and complete a restore drill.
  • Add monitoring for readiness, payment failures, backup age, disk, and database latency.

Known functional limitations

  • Recurrence supports IANA timezones and daylight-saving-aware daily, weekly, and monthly rules. Before high-volume use, move occurrence expansion into a background job and define a long-range materialization horizon rather than generating every bounded occurrence in the request.
  • The current persistence adapter stores authoritative application state in one JSON row. Normalized Drizzle tables exist as the target schema, but production-scale query and migration work remains.
  • MobilePay and email are generic webhook adapters; provider onboarding, signature verification, retry handling, and webhook reconciliation are not yet implemented.
  • The administration interface covers the core demonstration flows, not every API operation.
  • The OpenAPI contract documents the public entry points but should be kept in lockstep as detailed schemas evolve.

Safe evaluation configuration

Preview environments intentionally use:

dotenv
STORE_MODE=mysql
DEMO_AUTH_ENABLED=true
EMAIL_ADAPTER=mock
PAYMENT_ADAPTER=mock

This combination exercises real MySQL persistence and ordinary authorization while making only email and payments deterministic. Never mistake a successful mock charge for a real payment.

Booking SaaS implementation documentation