Ongoing

Seirm

Solo Developed aided by Claude Code CLI · 2026 · 7 min read

Built a full-stack social gig tracker so I had one place to log concerts, discover upcoming events, share experiences with friends, browse venue histories, and keep a proper record of my live music life.

Overview

Seirm started as a personal itch: I kept losing track of gigs I'd been to, had no easy way to see what friends were attending, and was tired of reconstructing setlists from memory. It's now a Laravel-based web app with event discovery via geolocation, setlist imports, photo uploads, email reminders, a social activity feed, personal stats and insights, venue profiles, and a PWA that installs on my phone like a native app.

Problem

There's no single app that does all of this the way I want. Streaming services track what you listen to, ticketing apps track what you've bought, and setlist.fm knows what was played — but none of them talk to each other, and none of them have a social layer built around the people I actually go to gigs with. I wanted something that pulled all of it together, including support acts, comments, and a shared activity feed.

Constraints

  • It needed to work well as a mobile app without the overhead of a native build
  • Third-party API access (Ticketmaster, Skiddle, setlist.fm) had to be optional — the app still needed to work without them
  • Photos, tickets, and setlists all needed to be stored reliably without reaching for expensive cloud storage
  • The social features had to be lightweight enough to build solo without becoming a full-time project
  • Registration needed to be lockable so I could keep it invite-only if needed

Approach

I built it on Laravel 11 with Blade templates and a dark/orange custom theme, keeping the frontend deliberately simple — vanilla JS, Vite, no heavy framework. The backend does the heavy lifting: API integrations with Ticketmaster and Skiddle (with geolocation support to find nearby events), setlist imports from setlist.fm, local disk storage for photos and PDF tickets, and a notification system covering in-app alerts, email reminders, and a weekly digest. The whole thing is installable as a PWA with an offline fallback. It's hosted on an existing Ubuntu based virtual server running Plesk and hosted on Azure in the UK.

Key Decisions

Use Laravel Blade instead of a JS framework

Reasoning:

For a solo project where the UI is secondary to the data model, Blade is faster to work with and keeps the codebase simpler. I wanted to ship features, not configure component pipelines.

Store files locally rather than in cloud object storage

Reasoning:

For a self-hosted personal app, local disk is fast, free, and entirely under my control. The added complexity of S3 or similar wasn't worth it at this scale.

Make all third-party API keys optional

Reasoning:

Ticketmaster and setlist.fm are useful additions, not core features. Designing around their absence from the start kept the app usable even when API limits or key issues crop up.

Build a PWA instead of a native app

Reasoning:

Installable on iOS and Android without managing app store submissions or maintaining separate codebases. For a personal project, that tradeoff is obvious.

Confirmed-only friend attendance model

Reasoning:

Keeping the friends system opt-in and confirmation-based means the social layer stays accurate — you only see friends who've explicitly connected, and gig attendance shown to others is intentional.

Tech Stack

  • PHP 8.5
  • Laravel 11
  • Laravel Breeze
  • Blade templates
  • MariaDB
  • Vite
  • Ticketmaster API
  • Skiddle API
  • setlist.fm API
  • spatie/icalendar-generator
  • intervention/image
  • PWA

Result & Impact

  • seirm.uk
    Live at
  • Session-based (Laravel Breeze)
    Auth
  • 3 (Ticketmaster, Skiddle, setlist.fm)
    API integrations

Seirm replaced a mix of memory, calendars, and ticketing app history with something that actually works the way I want. The setlist import saves a lot of post-gig effort, the geolocation-aware event search makes discovery genuinely useful, the iCal feed means my gig calendar shows up everywhere without any manual syncing, and the stats page gives a satisfying overview of artists and venues I keep coming back to.

Learnings

  • A focused data model goes a long way. Gig → artist, support acts, venue, date, notes is simple, but it unlocks everything else cleanly.
  • The PWA approach is genuinely underrated for personal web apps — installable, offline-capable, and zero app store overhead.
  • Optional integrations are worth designing for from the start. Making API keys truly optional meant I never had to hack around missing credentials.
  • Building the social layer solo is very doable if you keep it simple: confirmed friendships, an activity feed, and targeted notifications cover most of what makes it worth sharing.

What it is

Seirm is a personal concert tracker with a social layer. You log gigs you’ve attended or plan to attend — including support acts — search for upcoming events via Ticketmaster and Skiddle with geolocation support, pull in setlists automatically from setlist.fm, upload photos and PDF tickets, leave comments on gig pages, and see what your friends have been up to in a shared activity feed.

It’s live at seirm.uk and installable as a PWA with an offline fallback, so it behaves like a native app on my phone without any of the app store overhead.

The app was originally called GigBuddy, but a search for other apps with the same name turned up enough conflicts that a rebrand made sense before going any further. The name Seirm comes from the Scottish Gaelic word seirm (pronounced “SHARE-um”), meaning sound, ring, melody, or chime. It felt right for something built around live music, and it’s distinctive enough that it’s actually mine.

Why I built it

I go to a lot of gigs. I’d lost track of half of them, had no record of what was played, and found myself trying to reconstruct setlists from memory weeks later. Ticketing apps only cover what you bought through them, and setlist.fm is great for looking up what was played but not for tracking your own history or coordinating with friends.

Seirm pulls everything into one place: the log, the discovery, the setlists, the photos, the comments, and the social feed.

How it works

The core of the app is the gig log — you record the artist, any support acts, venue, date, and notes. From there you can:

  • Discover events by searching Ticketmaster or Skiddle, with geolocation to surface events near you, and import them directly
  • Import a setlist by matching on artist, date, and venue via the setlist.fm API
  • Upload photos (artist header plus a gig gallery) and PDF tickets
  • RSVP to upcoming events as attending, maybe, or watchlist — and see which confirmed friends are going
  • Invite friends to specific gigs via a token-based invite link, so non-registered users can join without needing an account first
  • View stats — personal gig counts, top artists, and top venues
  • Browse venue profiles — see every gig logged at a given venue
  • Subscribe to your gig calendar as an iCal feed, with one-click links for Apple Calendar and Google Calendar
  • Export your full gig history as CSV, including support acts

The activity feed shows what friends have logged and RSVPed to. Notifications fire when someone joins a gig you’re attending. Email reminders go out the day before upcoming gigs, and there’s an optional weekly digest — both configurable per user.

Tech choices

The backend is Laravel 11 with MariaDB, and the frontend deliberately avoids heavy frameworks — Blade templates, custom CSS with a dark/orange theme, and vanilla JS built with Vite. For a solo project where the UI needs to be good but isn’t the point, that’s the right level of complexity.

Files (photos, PDF tickets, avatars) live on local disk. It’s self-hosted, it’s fast, and it doesn’t need an S3 bucket. The setlist import is powered by SetlistFmService, which searches by artist, date, and venue, with a fallback to artist and date only when the venue can’t be matched.

PWA

The app ships as a Progressive Web App with an offline fallback, so it installs cleanly on iOS and Android from the browser. No separate codebase, no app store approval process. For something I’m building and maintaining solo, that’s the obvious choice.