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.
• Turn DEMO_MODE off; this removes demo seeding and token disclosure.
• 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

• Recurring schedules currently calculate occurrences in UTC. A studio timezone and daylight-saving-aware recurrence engine is required before relying on local weekly schedules across clock changes.
• 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:

STORE_MODE=mysql
DEMO_MODE=true
EMAIL_ADAPTER=mock
PAYMENT_ADAPTER=mock

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