# Build brief — a focused alternative to tcgevents

> **Verdict:** Not faithfully · **Buildability:** 6/100 · **Category:** Community
> **Source:** https://www.canitbevibecoded.com/tcgevents
> Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from tcgevents. Verify current pricing and capabilities before acting.

## Context

**tcgevents** — Finds and lists trading card game tournaments and local store events so players know where to show up.

The software here is a searchable list with a map and some filters, which an agent can produce before your coffee cools. The product is not the list, it is the fact that events are in it: store owners posting schedules, organizers keeping dates current, players trusting it enough to check it weekly. Scrape it and you own a snapshot that starts rotting the moment a shop moves its Friday night draft. Official publisher locators exist, but they are partial, rate limited, and hostile to bulk use, and the small local scene stuff never appears there at all. Build the personal tracker if you play in two cities, but do not pretend it replaces the directory.

This brief describes a focused, single-operator replacement for the part of tcgevents that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.

## What you are building

A local event tracker where you paste or manually add tournaments, then browse them by game, date and distance with calendar and ICS export.

- Publish a members-only feed with accounts, moderation tools, and digests.
- A responsive interface with real empty, loading, success, and error states.

## Requirements

### Functional

- Somewhere to actually get event data: official store locators, store Discords, Facebook pages, or your own typing.
- Ongoing willingness to maintain your own listings, which is the entire catch.

### Data and integrations

- Optional geocoding API key in .env if you want distance filtering.

Each of these needs a real account, credential, or quota. Set them up before writing feature code.

### Non-functional

- Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.
- Security: server-side secrets, validated input, and no credentials in the client bundle.
- Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.
- Portability: the operator can export their data and leave without losing it.

## Implementation brief

Build a local-first trading card game event tracker. Single Python project, no accounts, no cloud, no telemetry.

Stack, non negotiable:
- Python 3.11, FastAPI, Jinja2 templates, SQLite via sqlite3 stdlib
- Plain server rendered HTML plus a little vanilla JS, no build step, no npm
- Leaflet from a CDN for the map, OpenStreetMap tiles

Data model (events): id, game (magic, pokemon, yugioh, lorcana, other), title, format, venue_name, address, city, country, lat, lon, starts_at (UTC), ends_at nullable, entry_fee nullable, url nullable, notes, source (manual or paste), created_at, updated_at.
Also a settings row for home_lat, home_lon, default_radius_km.

Features, in scope:
1. Add and edit events through a simple HTML form. Manual entry is the primary path, treat it as first class.
2. A "paste dump" page: textarea where I paste messy text from a store Discord or Facebook post, plus a parser that extracts candidate title, date, time and fee with regex and dateutil, then shows an editable pre-filled form. No LLM call. If parsing fails, say so and let me fill it in.
3. List view: filter by game, date range, city, and distance from home using haversine on stored lat/lon. Sort by starts_at.
4. Map view: pins for filtered events, popup with title, time, venue, link.
5. Calendar: current month grid, events per day.
6. Export: /export.ics returns a valid VCALENDAR of the current filter. Also /export.json.
7. Geocoding: optional. If GEOCODE_PROVIDER and GEOCODE_API_KEY are set in .env, geocode addresses on save; otherwise leave lat/lon null and hide distance filters gracefully.
8. Recurring events: a weekly repeat option that materializes the next 8 occurrences, each editable and cancellable individually.

Out of scope, do not build: user accounts, multi tenancy, scraping any third party site, push notifications, a mobile app, anything that pretends to have nationwide coverage.

Deliverables: app.py, db.py, parse.py, templates/, static/, schema.sql, .env.example, seed.py with 12 fake events across 3 cities, and a README with run instructions (uvicorn, one command). Include pytest tests for the parser and the ICS output. Timezones: store UTC, display in a TZ set in .env, default America/New_York.

## Delivery standard

- Inspect the repository first, then write a short implementation plan before writing code.
- Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.
- Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.
- Include responsive layouts plus genuine empty, loading, success, validation, and failure states.
- Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.
- Add structured logs around every external call and return actionable errors without leaking sensitive details.
- Write unit tests for the core logic and one automated test of the main user journey.
- Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.

## Acceptance criteria

- [ ] A clean install starts the app using only the README and .env.example.
- [ ] The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.
- [ ] Invalid input, missing configuration, provider failure, and an empty database each have a usable state.
- [ ] The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.
- [ ] Tests, type checking, linting, and a production build all pass with no ignored failures.
- [ ] No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.

## Non-goals

Do not build these, and do not claim to have replaced them:

- Coverage: every store you did not personally enter is invisible.
- Freshness: cancellations, venue changes and date shifts arrive nowhere.
- Organizer side: shops have no reason to tell your laptop about their new league night.
- Discovery for travel: the whole point of a directory is events in cities you do not know.
- Whatever normalization the real site does across games, formats and regional naming chaos.

## What you still own after launch

- Secure credentials, rotate secrets, and handle provider rate limits.
- Run migrations, backups, restores, and dependency updates.
- Test the critical journey after every model, API, or hosting change.
- Monitor failures and fix the edge cases a first prompt will miss.

## Risk

**Operational risk.** The code is achievable; dependable data, integrations, and ongoing operations are the real cost.

Editorial confidence in this assessment: low. No reviewed project implementation is linked yet.

---

Generated by [Can It Be Vibe Coded?](https://www.canitbevibecoded.com) · Full report: https://www.canitbevibecoded.com/tcgevents