Show Scout

The problem I actually had

I like theatre. I kept missing shows I would have travelled for, because regional programming is announced across a few hundred venue sites, a handful of producer newsletters, and nowhere else. There is no index. If you want to know that a touring production is playing three hours from you in October, the only reliable method is to go and look, repeatedly, forever.

So the product question was not "how do I build a theatre database". It was: what is the smallest system that can tell someone something they would have missed, without either of us doing any work?

What it does

You add shows to a watchlist and cities you would travel to. After that you do nothing. When a performance turns up that matches both, you get a message.

How a match becomes a message

The hard part was time

A performance has a date and a time, and both are meaningless without a place. A 7:30pm curtain in Ashland is not the same instant as a 7:30pm curtain in Chicago, and a user in a third timezone needs to be told about both correctly.

I settled this at the schema layer rather than in application code, so that every consumer of a performance row — the matcher, the email template, the mobile app — inherits the same answer instead of each re-deriving it.

create table performances (
id            uuid primary key default gen_random_uuid(),
production_id uuid not null references productions(id),
venue_id      uuid not null references venues(id),
-- the moment in time, always UTC
show_datetime timestamptz not null,
-- what the audience sees on the ticket
local_date    date generated always as (
                (show_datetime at time zone venue_timezone())::date
              ) stored,
status        text not null default 'pending'
              check (status in ('pending','approved','rejected'))
);

The matching job

The obvious implementation is a loop: for each user, fetch their watchlist, fetch their cities, query performances. That is an N+1 with a network hop per user, and it gets slower exactly as the product succeeds.

Instead the join lives in Postgres as a function on a pg_cron schedule. One query plan, one transaction, and the write into matches is the same statement that found them.

insert into matches (user_id, performance_id, matched_at)
select w.user_id, p.id, now()
from watchlist w
join user_cities uc on uc.user_id = w.user_id
join performances p on p.production_id = w.production_id
                 and p.venue_city_id  = uc.city_id
where p.status = 'approved'
and p.show_datetime > now()
on conflict (user_id, performance_id) do nothing;

Where Claude sits in the product

Scraped listings arrive as free text. Titles vary, venues abbreviate, and the same production appears under three names in a week. Claude normalises those into a candidate record, which then goes to a human — me — for approval rather than straight into the catalogue.

Decisions

What is not done

• REVISE: Be honest and specific here. Unfinished work described precisely reads as judgement; described vaguely it reads as an excuse.
• The React Native / Expo companion app is scaffolded and lives in its own repo.
• Monetization is designed but not switched on — lifetime-subscription caps against Stripe, chosen over Patreon for entitlement control.

Where it landed

• REVISE: waitlist signups since the coming-soon page went up
• REVISE: performances indexed / venues scraped
• Matching runs unattended on a schedule — no manual curation step