Case study · Independent product
Next Gig
I designed and built Next Gig so working musicians can organise gigs and find cover without losing the details in group chats.
- My role
- Solo product designer & full-stack developer
- Timeline
- 2025 - present
- Built with
- React · TypeScript · Tailwind · Firebase
- Stage
- Live alpha · pilot musicians giving informal feedback
A working product, end to end
One place for the next gig
A schedule for the musician, offer controls for finding cover, and an earnings view for the admin afterwards.
One key decision: let band leaders choose between contacting the whole roster for speed and offering the gig in order, giving each player time to respond.
01 Context & ownership
A problem I know from both sides of the stage
As a working bass player, I know the logistics of gigging first hand. Dates, fees, venue details and availability are often spread across WhatsApp groups, messages and notes. Finding someone to cover a gig adds another thread to keep track of.
I designed and built Next Gig myself, from the interaction flows and visual design to the React interface and Firebase backend. Building it myself means I can test the fiddly parts, like sending offers, in a real product.
The starting point was my own experience. A pilot group now helps me check functionality and gives feedback through conversation.
02 Design decisions
Here are three decisions that shaped the app.
1. Put the booking essentials in the list
Each gig in the My gigs list shows when and where it is, and what it pays. Upcoming, Past and Offers separate different tasks without asking a musician to open every gig to understand their schedule.
The trade-off: the list stays compact. Longer notes, resources and lineup details belong in the gig detail view. View the schedule screen.
2. Make the offer terms explicit before sending
The Share gig sheet brings the dep fee and offer order alongside the selected roster. A band leader can choose to contact players all at once or in order, with the response window explained next to that choice.
The trade-off: an ordered offer gives each player time to respond, while contacting everyone at once prioritises speed. Keeping both options visible leaves that judgement with the musician.
Here, the roster is the pool of substitutes to contact, rather than the confirmed band lineup.
3. Keep earnings connected to the gig
The earnings view brings income and expenses into a separate place to review. It takes the app past finding a dep, into the admin after the gig.
The trade-off: this adds value beyond booking, but also adds scope. It has to earn that extra complexity.
03 A closer look
Adding the lineup to the gig screen
The earlier detail view focused on the date, fee, venue and notes. The later version retains those essentials and adds explicit gig status and lineup information, so the page can also explain who is playing and who has arranged cover.
Earlier version
Later version
The captures show different gigs at different stages of the product. Both screens use demonstration data.
04 Pilot & next steps
Live, but early
Next Gig is a live, installable alpha. The pilot group is helping me check that things work and sharing general feedback through conversation. I have not yet captured formal usability findings or verified outcome metrics.
Next, I want to follow a musician through offering and covering a gig, note where they hesitate, and see whether the app keeps them informed without extra messages.
Questions for the next round of validation
- Whether a band leader can send an offer without help.
- Whether both sides understand the fee and the booking status.
- Where coordination still moves back into WhatsApp.