Luma

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me an events page that replaces Luma: a page per event, RSVPs that mean something, and reminders that go out on time.

STACK
- Node 20+ with Fastify, server-rendered HTML, minimal JavaScript
- SQLite through better-sqlite3, WAL mode
- Stripe for paid tickets, or nothing at all when the event is free
- Caddy in front, one process on a small VPS

THE DATA MODEL
- events: id, slug, title, description, starts_at, ends_at, timezone, location_kind, location, capacity, visibility, requires_approval, cover_image, host_id, created_at
- registrations: id, event_id, name, email, status, ticket_id, answers_json, created_at, approved_at, checked_in_at, cancelled_at
- tickets: id, event_id, name, price_cents, currency, quantity, sold, sales_start, sales_end
- guests: id, email, name, created_at — one person across events, so a returning attendee is recognisable
- reminders: id, event_id, offset_minutes, channel, sent_at
- calendars: id, slug, name, description — a series of events under one address
- Location kind is in_person, online or hybrid; store the join link separately and reveal it only to approved registrations

THE EVENT PAGE
- One page, no scrolling for the essentials: title, when in the reader's own timezone with the original one beside it, where, who is hosting, and one button
- The register button changes with the state: register, join the waitlist, request an invitation, sold out, or it already happened
- Guest list optional, and when it is on it shows names and avatars, never emails
- Add to calendar for Google, Outlook and .ics, with the .ics generated correctly — a wrong VTIMEZONE is why calendar invites land an hour off
- Cover image, and an OG card generated per event with title, date and location so a shared link looks like something
- The description takes Markdown

REGISTERING
- Name and email, and nothing else unless the host adds questions
- Custom questions per event: short text, long text, choice, checkbox, each optional or required
- Approval mode: a registration waits, the host approves or declines, and the guest is told either way
- Capacity with a waitlist that promotes automatically when somebody cancels, oldest first, and tells them
- One registration per email per event, and a second attempt shows their existing ticket rather than a duplicate
- No account required to register. A signed link in the email is how somebody manages their registration afterwards

TICKETS AND MONEY
- Free events do not touch Stripe at all
- Paid tickets through Stripe Checkout, with the webhook confirming the registration — never trust the redirect back
- Multiple ticket types with their own price, quantity and sales window
- Refunds from the host page, which cancel the registration and free the seat
- Store what was charged, in cents, with the currency, and reconcile against Stripe rather than assuming

REMINDERS AND EMAILS
- Confirmation immediately, with the calendar file attached and the join link if it is online and approved
- Reminders at intervals the host sets — a day before, an hour before — sent from a worker that wakes every minute and is safe to run twice
- A message to everybody who registered, written by the host, before or after the event
- Every email says which event it is about in the subject and carries an unsubscribe that does not need a login

CHECK-IN
- A check-in page for the host on a phone: search by name, tap to check in, works offline for a whole guest list and syncs when the signal comes back
- A QR code in each confirmation email that check-in can scan
- Numbers on the host page: registered, approved, checked in, and the no-show rate afterwards

THE HOST SIDE
- Create an event in one screen with sensible defaults; everything else is optional
- Duplicate an event, because the second one is usually the first one again
- A calendar page listing upcoming and past events at one address, with an RSS feed and an .ics subscription
- Export registrations to CSV

THE INTERFACE
- The event page reads well on a phone first: that is where a shared link is opened
- Dates always in the reader's timezone with the event's own timezone stated
- Dark and light, one accent, no cookie banner because there are no cookies to consent to

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, SMTP_URL, STRIPE_SECRET, STRIPE_WEBHOOK_SECRET, TOKEN_SECRET
- Migrations on boot, each once
- The reminder worker is idempotent: a reminder row is marked sent inside the same transaction that sends it
- Nightly backup off the machine, and a restore script
- Health endpoint that checks the database and the mail transport

WHAT MATTERS MOST
The event page and the registration flow are the product, and the calendar file is the part everybody gets wrong. Build those three, test the .ics against Google Calendar, Apple Calendar and Outlook, and only then add tickets and reminders.

Give me the repository, migrations, .env.example, a seed with one free and one paid event, and a README with deploy steps behind Caddy.