Events Platform (working name)

Next-generation replacement for the WordPress/Listify stack currently running HeyAustin.com, HeyCrestedButte.com, 6thStreet.com, and LakeTravis.com.

Built from scratch, as a side project, in parallel to the live WordPress sites. Nothing here touches production until a pilot site is ready to cut over.

Target architecture

• Frontend: Next.js, one codebase serving all 4 branded sites (per-site theme/config)
• Database: Supabase (Postgres)
• API: Single API serving all 4 websites + 2 mobile apps
• Admin: Custom curation portal (replaces wp-admin)
• AI: LLM-driven event ingestion from partner venue pages + SEO content generation

Roadmap

1. Unified data model (/schema)
2. Single API
3. AI event ingestion pipeline (builds on the existing vee.py prototype)
4. Custom admin/curation portal
5. Next.js multi-site frontend
6. Pilot migration + cutover plan

Prior art

vee.py ("Venue Event Evaluation") — an existing prototype found on the build machine at ~/.grok/skills/vee/scripts/vee.py. It already discovers partner venue calendars, scrapes their events, and diffs them against what's published on HeyAustin (matched / missing-on-site / missing-on-venue). This is real prior art for the AI ingestion phase, not a from-scratch problem.

Live-site recon (2026-07-05)

Checked all 4 sites: HeyAustin.com, LakeTravis.com, HeyCrestedButte.com, 6thStreet.com. All four share one underlying stack:

• Theme: Listify (+ a heavily customized listify-child)
• Venues: WP Job Manager (job_listing post type), with a separate region taxonomy (job_listing_region) alongside topical categories (job_listing_category) — e.g. region "North Shore" vs category "Distilleries"
• Events: partly manual, but a large share (1,709 of 1,966 checked across 2 sites) come from an automated Facebook Events importer (facebook_events post type, fbevents/v1 REST namespace) — this is existing automation, not AI
• Rentals: a 4th content type (rental post type) — vacation/property rentals, distinct from venues and events
• Mobile apps: both HeyAustin's and LakeTravis's apps run on Listar, a commercial WP REST API plugin (separate product from the Listify theme) exposing place/*, event/*, blog/*, wishlist/* (favorites), auth/* (real public user accounts), and author/booking. This is a working API contract already in production — informs the new API's shape directly.
• Ratings/reviews exist on venues and events (schema.org AggregateRating
  • rating_avg/rating_count fields in the live API responses)
• Maps: Mapbox client-side, plus per-venue Google Maps driving-directions links
• Security posture: Wordfence active on all 3 (xmlrpc.php blocked, REST user enumeration blocked); LakeTravis sits behind Cloudflare, HeyAustin and CrestedButte do not (raw Apache) — infra isn't fully identical across sites
• Scale: LakeTravis 257 venues / 1,709 events; CrestedButte 177 venues / 741 events
• Booking: listar/v1/author/booking is GET-only (paginated list, no create/POST), and no site has a booking-type entry in its sitemap. Read as a dormant Listar theme feature (the theme supports booking-style directories generically), not an active system on any of the 4 sites. Left out of the schema — flag if this is wrong.
• 6thStreet is on plain AWS/Apache like HeyAustin and CrestedButte (no Cloudflare), but is the only one of the 4 with X-Frame-Options set — infra hardening is inconsistent across sites, not just a HeyAustin gap.

These findings are reflected in schema/001_initial_schema.sql (rentals, regions, app_users, favorites, reviews, search_documents tables, plus is_featured/rating_avg/rating_count fields).