Almost two years ago I put the first version of Gigz on the App Store. The idea was simple. Music fans go to dozens, sometimes hundreds of shows over a lifetime, and most of us have no good way to remember them. What was that band at The Corner Hotel in 2008? Who opened? What did they play? People were patching it together with Instagram highlights, Notes, and spreadsheets. None of those were built for the job.
Version 1 answered that question in the most direct way I could manage. A card-based timeline grouped by year, a setlist if one existed, and up to five photos per show. It worked, and people used it. But it had one flaw I could not design around: you had to type everything in yourself. Artist, venue, date. Every show was a small data-entry task, and a diary that feels like data entry does not get kept.
This post is about the rebuild that fixes that, the decisions behind it, and how it was made.
The idea has not changed
Gigz is still a chronological diary of the shows you have been to. That is the mental model everything else hangs off. Not a feed, not a leaderboard, not a ticketing app. A collection you scroll back through, where each entry holds the songs they played and the photos you took.
What changed is everything around that idea. The data is now already there waiting for you. There are stats and achievements built from your history. There is a friends layer, kept deliberately quiet. And there are upcoming shows, so the diary can look forward as well as back.
The rest of this post is the three decisions I care most about.
Decision one: the app should already know the show
The biggest problem with version 1 was the blank form. Adding a show meant recalling and typing the artist’s name, finding the venue, picking the date. If you were logging a gig from 2011, you were often guessing at two of the three.
In 2.0 you search an artist and Gigz shows you every gig they have played in your city. You find the one you were at and tap Add. That is the whole flow. Artist, venue, date, and setlist come with it.
This sounds like a small change and it is not. It moves the app from “record what you remember” to “recognise what you did.” Recognition is much easier than recall. Seeing “Forum Theatre, 14 March 2019” in a list snaps the memory back in a way a blank date picker never will. And it means the diary you build is consistent. Two people at the same show are logging the same show, not two slightly different spellings of it.
It also set the bar for everything else. Once artists, venues, and shows are real records rather than strings a user typed, you can compute things from them. Which brings me to stats.
Stats and achievements were on the wish list from the start, but they were impossible in version 1 because the data was free text. Now the app can tell you how many times you have seen a band, which venue you keep coming back to, and how your year compares to the last one.
Decision two: social, but not front and centre
Every product review I read while researching version 1 said the same thing about the adjacent apps: they were community-focused, not me-focused. I wanted Gigz to be personal first. But there is an obvious pull toward the social side. The best gig conversations start with “were you at that one too?”
So 2.0 has friends, and I spent more time deciding what they cannot see than what they can.
The rules are simple. Friendships are mutual. A friend can see the shows you have attended, and only if you have sharing switched on. Upcoming shows are private by default. If you want a particular friend to see what you have coming up, you grant that per friend. Nothing is public. There is no discover tab, no follower count, no feed of strangers.
The reason for the per-friend upcoming grant is worth spelling out. A past show is a memory. A future show is a plan, and plans are more sensitive. Who you are going with, whether you are in town that weekend. I did not want to build something where accepting a friend request also broadcast your calendar. Making the default private and the exception explicit costs a little convenience and buys a lot of trust.
Keeping the social features out of the way was also a layout decision. They live where you go looking for them, not where you land. The home screen is still your diary.
Decision three: look forward, not just back
Version 1 only knew about shows that had already happened. The most common thing I heard from people who used it was some version of “I missed that tour.” So 2.0 adds upcoming shows. You follow the artists you care about, and their announced dates in your city show up. When the night comes and goes, the show moves from upcoming to attended with your photos attached.
This closes a loop I always wanted. The same record that tells you what a band played last time can tell you they are back in November.
How it was built
I will keep this to the parts that matter for the product, but I do want to talk about the build, because it is the part of the last two years I am most proud of.
Gigz 2.0 is a SwiftUI app on iOS 26 with a single backend that owns all the data and every rule about who can see what. The iOS app never decides visibility on its own. It asks the server, and the server holds the rules described above. That is what lets me be precise about privacy. There is one place the controls live, and it is not on the device.
Having one backend is also what makes the next platform possible. An Android build is coming, and it will talk to the same server, with the same rules, against the same data. The privacy model does not need to be rebuilt for a second client.
Working with agents
This was the first project where I built with agentic tooling from start to finish, and I want to be specific rather than vague about it.
I used Claude Code for most of the implementation. The way I settled into working was to have the top-tier model act as the orchestrator, breaking work down, making judgment calls, and reviewing, while Opus and Sonnet did the bulk of the implementation and testing as workers. The expensive model thinks, the cheaper models build, and I decide.
What made it work was not the models. It was the discipline around them. Every product decision and every piece of work is tracked in Linear, so an agent picks up a ticket with the context already written down, and the review happens against what the ticket asked for. The rules that matter, like “upcoming shows are private by default” or “the client never decides visibility,” are written into the project so every agent starts with them.
The honest summary is that agents made me faster at building and slower at deciding, in a good way. When implementation is cheap, the bottleneck moves to being clear about what you want. Most of my time went into that.
What it took
Version 1 shipped in March 2025. Version 2.0 is on the App Store now: Gigz App Store. In between there was a full rebuild of the data model, a new backend, a new privacy model, a redesigned app, and a lot of nights trying to get one small interaction to feel right.
I am telling you this because I want the care to be visible. Nothing in Gigz is there because it was easy to add. The Add flow is three taps because I removed everything else. The social features are quiet because I turned them down. The defaults are private because I chose them that way.
What is next
Gigz covers Australian cities only at the moment. More are coming.
The next feature I am building is On This Day: a memory from your diary resurfaced on its anniversary, with a Gigz ticket stub you can share to social platforms. Each stub is designed for the show, so it is yours, not a generic card.
After that, links to ticket platforms for upcoming shows, and reminders when an artist you follow announces a tour.
If you have a pile of shows in your head that you have been meaning to write down, Gigz is the place for them. It will not make you type them in.