TourScout

TourScout shows independent musicians and comedians where their next fans are, and a GitLab Duo flow carries every change from a work item to a production deploy I approve.

Comment

Inspiration

Independent musicians and comedians plan tours from gut feel and old gig history. That finds the fans they already have, not the ones they haven't met yet. And a solo developer building a tool for them has the opposite problem: no team to review, test, secure and ship every change. TourScout is my answer to both.

What it does

TourScout reads Qloo's taste data to rank cities by Fan Match, finds the "untapped" cities where acts like yours are loved but you aren't known yet, and plans a routed, dated tour with venues, local openers and promotion partners for every stop. You just chat: "I'm Wet Leg. Where am I not known yet?" The answer comes with its evidence (for example, "Fans of Fontaines D.C. over-index here; you're not big here yet"), and every card opens into a full view on the map. A new act that no taste graph knows yet starts from up to three acts it sounds like.

How I built it: life after code

I build and run TourScout on my own, under a data licence that forbids publishing Qloo's data, so every change has to ship safely without a team behind it. GitLab carries each change from an idea to production, touching all nine lifecycle stages:

  • Plan → Create: a work item from the Agent task template is assigned to my custom GitLab Duo flow, TourScout issue to production. Its planner posts a plan on the work item (or says what's missing), its developer branches, implements, tests and opens the merge request, and its reviewer posts an audit note back on the work item. Run 1 took work item #2 (a High-severity braces vulnerability) to a green merge request in five minutes; run 2 took work item #3 to the untapped-cities feature shown in the video (merge request !3).
  • Verify, Secure: every merge request runs 14 jobs: lint, types, 390 unit tests, Firestore security-rules tests on the emulator, Playwright journeys on desktop and phone, SAST, secret detection, dependency and container scanning. GitLab Duo Code Review reviews against TourScout's own rules.
  • Govern: policy as code tied to the domain. govern:qloo-data fails the pipeline if any Qloo response, image or cache appears in the repository; govern:licences allows only OSI-approved licences; govern:autonomy fails if the flow's declared autonomy level and the pipeline's disagree.
  • Package, Release: after I merge, main builds a distroless image, mirrors it to Artifact Registry, deploys staging on Cloud Run and smoke-tests it. Production waits for my approval: supervised autonomy.
  • Configure, Monitor: production deploys, runs its smoke tests, rolls itself back to the previous revision if they fail, applies the Firestore rules and indexes from the repository, and warms the cache. Every deployment is tracked in GitLab Environments.

The switch to hands-off is one line: the flow's Autonomy level and the AUTONOMY_LEVEL CI/CD variable, kept in step by govern:autonomy.

The app is Next.js and TypeScript with MapLibre maps, Firebase Auth and Firestore, on Google Cloud Run with secrets in Secret Manager.

Challenges I ran into

  • Qloo's terms forbid publishing its data, so tests run on synthetic fixtures and a pipeline job guards the repository against any Qloo response slipping in.
  • The flow can't request GitLab Duo Code Review itself yet (it fails with DCR4008), so a person requests it; the flow does everything else.
  • Keeping one person in charge without slowing down: agents do the routine work, the pipeline proves it, and I approve two things only, the merge and the production deploy.

Accomplishments that I'm proud of

  • One work item reaches production through all nine lifecycle stages, with policy guarding the data licence and an automatic rollback if production's smoke test fails.
  • The main pipeline runs 21 jobs and 443 tests; a broken smoke test rolls production back without waiting for anyone.
  • A solo developer gets a team's safety net.

What I learned

How far a flow of narrow agents (plan, build, review) gets when the pipeline holds the line: the agents can be ambitious because the policy jobs, tests and scanners decide what passes, and a person decides what ships.

What's next for TourScout

Hands-off mode for low-risk work items (the switch already exists), an agent that turns a failed production smoke test into a work item with its own plan, and tour planning that books holds with venues.

Links

Built With

  • artifact-registry
  • cloud-firestore
  • docker
  • firebase
  • gitlab
  • gitlab-ci
  • gitlab-duo-agent-platform
  • gitlab-duo-code-review
  • google-cloud-run
  • maplibre
  • next.js
  • playwright
  • qloo
  • react
  • secret-manager
  • tailwind-css
  • typescript
  • vitest
Share this project:

Updates

Submission history