FestDaily
Discover, save, and never miss the local events you'd actually want to go to.
FestDaily helps city residents and families cut through disorganized event info — scattered across social media, easy to forget, hard to search — and turns it into a searchable, filterable, personal event calendar.
Naming note: this repository and its packages are still named festgrid (its original working name). The product itself was renamed FestDaily partway through development; all docs below use the current name.
Screenshots
Left: the mobile discovery feed as it renders today (Indonesian locale, signed out, scrolled to the large-poster cards), captured with Playwright from a production build against the seeded local demo data, so the events are test fixtures. The fixtures' image host no longer serves the files, so a generated sample poster was supplied for those images during the capture; the card layout is the app's own. Right: the design target the build is working toward — photo cards, status badges (ongoing / soon) and distance and end date on each card. The two are not the same yet.
Why this repo is worth a look
This isn't just a CRUD app — it's a fully spec-driven, AI-assisted build: every feature traces back to a PRD line item, an architectural decision, and a story file, all committed to the repo (see Planning & Process Artifacts). A few problems that came up along the way, and how they were solved:
-
Query sprawl across features. Discovery feed, favorites, calendar, and per-account public pages all needed "a list of events, filtered." Rather than grow a bespoke endpoint per view, every client query — regardless of feature — compiles down to one recursive JSON Unified Query DSL served by a single event-query endpoint. New views become new query conditions, not new endpoints. (architecture spine, AD-1/AD-2)
-
Trusting the wrong boundary. External input (scraped social posts, AI-extracted event data) and internal client input are different threat models, so they get different validators: AJV/JSON Schema guards the backend edge, Zod guards the frontend edge, and the two libraries are never mixed inside a shared package — a rule enforced structurally, not just by convention.
-
Silent data resurrection. A naive soft-delete makes it easy for one resolver to forget the deletedAt filter and leak a user-hidden or moderator-reverted row back into a list. Instead, the exclusion is enforced once, in the shared query-building layer that every event/favorite/calendar/subscription read goes through — backed by Postgres partial indexes on the active-row subset, so the common case stays fast. (AD-8)
-
Finding the bottleneck before it blocks anyone. Before implementation reached Epic 2, all six epics' readiness reports were synthesized into a ranked critical-path report — surfacing, for example, that the GraphQL auth-context layer (Story 0.17) alone gates four downstream epics. That story got prioritized ahead of schedule instead of being discovered as a blocker mid-sprint.
-
Compute-cost-aware AI workflow. Not every task needs the same model. Development uses semantic task-based routing: broad contextual analysis and user-story framing are delegated to an advanced reasoning LLM, while routine code generation is funneled to a lightweight, instruction-tuned codegen model — optimizing compute expenditure without sacrificing spec accuracy.
-
Velocity without cutting corners. Time is treated as a resource to budget deliberately, not just spend: the critical-path report above sequences gets built first, and two structural choices control each piece can be built and verified without quietly eroding quality — a (100% unit-test coverage is mandatory only in , the pure business-logic layer, and is enforced by a failing CI gate rather than left to convention — see ; a meta-testing/tooling package that verifies other code rather than implementing product logic — e.g. — gets its own qualitative-coverage unit-test tier instead; everything else follows a "testing trophy" of integration-first tests plus E2E coverage for critical flows only, so test effort scales with actual risk instead of blanket coverage targets) and (every package/app extends one base , and Turbo caches and parallelizes // per package so a change in one workspace doesn't force a full monorepo recompile).
This is the beginning of the README. Read the rest at the original. Read the full README ↗
