Atelier Studio — Booking Website (Frontend + Backend)

Two pages, plus a real backend — this is a DYNAMIC website, not a static one: 1. Book a Session (index.html) — the studio's booking form. Submits to /api/bookings. 2. Upcoming Bookings (dashboard.html) — a live, read-only list pulled from the same endpoint. WHOSE DATABASE. Yours, not this platform's. Before this site's booking form or dashboard will do anything real: 1. Create a Postgres database anywhere you like — Vercel Postgres, Supabase, Neon, or your own server all work, since the backend just speaks the standard Postgres wire protocol. 2. Run schema.sql against it once (any SQL client, or your provider's own console) to create the "bookings" table. 3. In your Vercel project's Settings -> Environment Variables, set DATABASE_URL to that database's connection string. This platform only ships the code in api/bookings.ts that reads and writes to whichever database you connect — it never provisions, stores, or has access to your data. MANAGING LIVE BOOKINGS. Once published, this purchase's library page shows a "Manage live bookings" panel that lists upcoming bookings and lets you cancel one — calling your deployed site's own /api/bookings endpoint straight from your browser, no redeploy needed. It needs a second Environment Variable, BOOKINGS_ADMIN_KEY (any secret string you choose — set it next to DATABASE_URL in the same Vercel project settings), which you then paste into that panel. That key is sent directly to your deployment, never to this platform's own servers, and only cancelling a booking requires it — listing them is public, the same as the dashboard page. AUTOMATED REMINDERS. This deployment also ships a scheduled job (Vercel Cron Jobs, declared in vercel.json) that runs once a day and emails a reminder to anyone booked for "tomorrow" who hasn't had one sent yet — set up once, no redeploy needed to keep it running. It needs two more Environment Variables: 1. CRON_SECRET (any secret string — required). Vercel signs its own cron-triggered requests with this, so the reminder endpoint can tell a real scheduled run apart from anyone hitting the URL directly. Without it, the cron endpoint refuses every request, including Vercel's own. 2. RESEND_API_KEY and REMINDER_FROM_EMAIL (optional). Sending an actual email needs your own Resend (resend.com) account and a sending address on a domain you've verified there. Until both are set, the cron still runs safely on schedule — it just reports how many reminders are due instead of sending them, so nothing is silently skipped once you do turn email on. Vercel's Hobby plan only allows daily cron schedules, which is exactly what this uses, so no paid plan is required for reminders to work. PREVIEW LIMITATION. The booking form and dashboard both call /api/bookings — a real endpoint once deployed, but this platform's own preview has no backend to call, so both show a friendly "try it once deployed" message here. That's expected, not a bug. The reminder cron has no preview equivalent at all — it only ever runs once deployed, on Vercel's own schedule. CUSTOMIZATION. The two frontend pages (copy, services, styling) work the same way as this platform's static website templates — describe a change and regenerate. The backend files (api/bookings.ts, api/cron/send-reminders.ts, vercel.json, package.json, schema.sql) ship as-is; they aren't run through the AI editor.