Copenhagen pilot status

Around Their Table is being prepared for its first real Copenhagen pilot. Guests can discover tables, create requests, follow request status, answer suggested times, and move to payment after host acceptance. Hosts can apply and review incoming requests while the final booking operations are completed.

Ready for early guests

• Explore the first Copenhagen table openings with clear date, time, area, price, duration, group size, and expectations.
• Search by city, date period, party size from 1 to 8, and experience type.
• Create an account, save guest preferences, and request a concrete table opening with date, time, guest count, dietary notes, and context.
• Follow each request from the profile with clear status cards: Requested, New time suggested, Accepted, Paid, Declined, or Closed.
• Accept or decline a new time when a host suggests one, then move to secure payment after acceptance.
• Save a simple private post-meal review note after a paid or completed booking.
• Receive cancellation and post-meal review request emails when those booking moments happen.

Payment readiness

The browser view and /api/status check the live Cloudflare environment for Stripe checkout configuration, webhook secret configuration, and webhook verification without exposing secret values. Admins can run Verify Stripe setup from /admin to test the Stripe account and webhook endpoint without creating checkout sessions or changing booking data.

Email readiness

Host application, table request, host response, guest suggested-time answer, cancellation, payment confirmation, and post-meal review request emails are implemented. Live delivery starts when the production Resend API key is set. The browser view and /api/status show readiness without exposing secret values.

Ready for host applications

• Learn what it means to host before applying.
• Create an account and submit one focused host application with a public table story and private review details.
• Approved hosts can create and edit table openings with title, format, price, date period, and guest limits.
• Review incoming table requests and accept, decline, or suggest another time.
• Save private host notes after a paid or completed booking without creating public ratings.
• Receive cancellation and post-meal review request emails tied to owned table bookings.
• Keep private address and safety details out of public pages.

Ready for reviewed launch work

• The team can review host applications with private address and safety details protected from public pages.
• The team can see every table request with guest, host, request status, suggested time, payment state, and private review notes.
• The team can mark paid bookings completed, so post-meal guest reviews and host private notes sit on the right booking state.
• Guests, hosts, and admins can cancel booking requests with a reason and audit trail.
• Every host application decision requires a review reason and creates an audit trail.
• Admin access diagnostics show the signed-in email, role, admin access state, and why access is blocked if it fails.
• A realistic Copenhagen pilot flow can be seeded for end-to-end testing without manual setup.

Being finished before the first paid pilot

• Add the first approved Copenhagen hosts and real table dates.
• Turn on tested Stripe production secrets and webhook handling, then run the admin Stripe setup check before real paid bookings.
• Set the production Resend API key and run live delivery checks for the already-built email notifications.
• Prepare refund handling, host payout operations, and the first real post-meal feedback dry run.

Internal pilot gate

• Approve the first Copenhagen host applications and table stories.
• Run one signed-in guest request through requested, suggested time, guest confirmation, host acceptance, and Stripe test payment.
• Confirm guest and host legal/trust copy before accepting real paid bookings.
• Set Stripe production secrets, webhook endpoint, refund owner, and payout owner.
• Prepare support handling for refunds, dietary issues, no-shows, and address sharing.
• Decide the first pilot capacity: number of hosts, table dates, and guests allowed in the first wave.