The project started while my friends and I were waiting for the bus that takes you up to Bilbao BBK Live.
We had already repeated the same routine a few times: someone asked what was playing next, one of us opened Instagram, found the festival's schedule post, zoomed in, checked the time, remembered the stage, and then looked for it on the venue map. The information was all there, but using it from a phone in the middle of the festival was slower than it needed to be.
I had also just finished setting up Hermes the week before, an AI coding agent, on a VPS. I use it through a Telegram group split into topics for different projects. Behind that group (in another VPS) were Gitea, Coolify, and Cloudflare, so a message from my phone could become code, a push, a deployment and a DNS update.
Until then I had mostly tested the pieces. Standing in that queue, I finally had a reason to try the full loop with something I might use that same evening. So I opened Telegram and sent a short message.
One request from the bus queue#
The first request was deliberately short:
Build me the timetable.
The first commit already had the three festival days, six stages, and 82 performances in a mobile schedule. The data was hardcoded from the published times. There was no API or import pipeline, which was fine: this was a tool for one weekend, and entering the programme once was faster than building machinery around it.
It also had the beginning of the feature I really wanted: a screen that answered "what is playing now?" without making us search the full timetable.
The first build was not the final design, but it was already useful. The idea was no longer a note for later; it was a deployed website I could continue changing from the festival.
The next request came from an artist I did not know#
A timetable gives you names, but festival lineups always include artists you have never listened to. I would see someone playing in half an hour and wonder what kind of music they made. Leaving the schedule, searching for the artist, and finding the correct Spotify profile brought back the same friction I was trying to remove.
So I asked Hermes to add Spotify. The first pass linked each artist to a Spotify search. Later, most of those searches became direct profile links, with search kept as a fallback where the exact profile was less clear.
The Now view also grew from the simple first screen into a stage-by-stage dashboard. The full programme stayed available by day and stage, with search for the moments when we already knew the name we wanted.
Then we needed to find the stage#
Spotify answered "who is this?" The remaining question was "where are they playing?"
Hermes added the venue map and placed each stage over the official image using simple percentage coordinates. The stage colours matched the timetable, and selecting one showed its location and programme. It was a basic implementation, but on the festival grounds it was exactly what we needed.
Artist sheets connected the rest of the flow. From a performance I could check its day, estimated time range, and stage, open the artist on Spotify, highlight the stage on the map, or share the details with friends.
That was when the project stopped feeling like a reformatted poster. The path from "what is playing?" to "do I like them?" to "where do I go?" now happened inside one small PWA.
The wristband was where it got interesting#
The timetable, Spotify, and map were useful, but the most surprising part of the project came from the cashless wristband.
The official flow used the QR attached to the wristband to open its top-up page. I first asked Hermes to make that easier to keep around. The PWA could scan the physical QR with the camera or read it from a screenshot.
Once scanned, the official top-up URL was stored only in local storage on that phone. The app also used the wristband identifier to fetch its information from the official flow, including the person's name. Instead of showing a generic wristband section, it could greet whoever had scanned it by name.
There was no app account or project backend, and the PWA did not process payments. It simply kept the official route one tap away and made the wristband feel like part of the app.
But saving the wristband was only the setup for the better question.
At the festival, the normal way to find the remaining balance was to go to a bar and ask. I asked Hermes whether it could find another way to check it from the wristband flow.
There was no official public balance endpoint. Hermes inspected the checkout process and noticed that the provider enforced a maximum credit. If a requested top-up exceeded that limit, the checkout returned an error containing how much additional credit the wristband could still accept.
That error exposed enough information to derive an estimate:
estimated balance = maximum credit - remaining allowed credit
The clever part was not finding a hidden balance API. There was none. It was realising that the credit-limit error already contained the missing information.
The app always labelled the result Estimated balance. It depended on an implementation detail in the checkout flow, not an official balance value, and it could break whenever that flow changed.
The first working version took about ten minutes, and it worked while we were at the festival. That was the moment Hermes stopped feeling like a fast code generator and did something I genuinely did not expect it to solve.
The wristband screen later added quick top-up amounts, while still handing the actual payment back to the official checkout. We also tried a custom amount UI, found it unreliable, and removed it a few minutes later. Moving quickly did not remove the need to test each result.
Building while using it#
After the first deployment, the loop stayed simple: send a message in the Telegram topic, wait for the deployment, and refresh the PWA on my iPhone. I could ask for the next change without leaving the festival or opening a laptop.
The requests came directly from using it. An unfamiliar artist led to Spotify links. Looking for a stage led to the map. Asking a bartender for the balance led to the wristband experiment. The festival was basically writing the requirements for us.
Hermes moved quickly, but the useful direction still came from being there with the same phone and the same friends asking what was next. Features changed or disappeared when they did not work in the real flow. That made this a more useful test than giving the agent a finished specification in advance.
After the last set#
When the festival ended, the app did not need to pretend that something was still live. It switched to a farewell screen and kept the schedule, map, and wristband sections available for reference.
A week later, I added another way to explore the project: an interactive timeline of its revisions. It lets you move through the original app states one commit at a time. The historical versions run with a fixed festival time, service workers disabled, and wristband storage blocked, so they can be explored without touching real data.
The current PWA is still online. The schedule, map, artist sheets, simulator, and project timeline remain useful for seeing what was built. The estimated balance no longer works because the event checkout has ended. That is fine: it was software for one weekend, and it solved the problem while the problem existed.
This was an unofficial personal project, with no affiliation to Bilbao BBK Live, Weezevent, or any payment provider. The programme came from published start times, set endings were inferred, and the balance was always an estimate. The screenshots in this post use fictional wristband details.
None of these small problems would normally justify pulling out a laptop in the middle of a festival. This time I did not even have one with me. A message from the bus queue was enough to start, and the result only had to be useful before the next band started.