Kigs. A social way to find nights that actually feel like you.
01Overview
Most discovery in underground music happens the way it always has. A friend texts you a name. You catch a flyer on Instagram. You end up on Resident Advisor to check the lineup, SoundCloud to audition a set, a group chat to sort who's actually going. Five stops for one decision. The culture has always run on that pinball machine.
Kigs started as an attempt to fix the fragmentation. Research reframed it within a few weeks. The fragmentation wasn't the wound. People had enough events. What they didn't have was enough signal to commit. A lineup alone wasn't moving anyone from maybe to let's go. The real problem was confidence, not discovery.
Results
~1,100 registered users in three months.
Zero paid acquisition. Launched October 2025.
Day-2 retention 18.9%.
Target 25–28%.
Day-7 retention 3.13%.
Target 10–15%. The clearest brief we have right now.
02About
Kigs is a discovery and planning app for underground electronic music. Built for people already inside the culture: fans, DJs, promoters, venues. Not a gateway product. The thesis: discovery in this space is socially mediated, not algorithmic. Trust is the substrate. Everything else is decoration.
The MVP exists to validate one thing: that people return. Once that's proven, the roadmap opens toward event ticketing and a platform giving promoters and venues the data to run more profitable events. Day-7 retention isn't just a product health metric. It's the gate to everything that follows.
03Problem
The brief came in as "fix fragmented discovery." On the surface that's an aggregation problem: pull events from Resident Advisor, Dice, Shotgun, Facebook, plus the WhatsApp groups and Instagram stories where most of it actually lives, and put them in one place.
Research sharpened it inside a few weeks. The fragmentation wasn't the wound. People had enough events. What they didn't have was enough signal to commit. A lineup alone wasn't moving anyone from maybe to let's go.
The cost when it goes wrong is real. Someone sees an event, can't confirm it's worth going, doesn't go. The moment passes. In a culture where trust travels through people rather than platforms, a missed night isn't just a bad recommendation – it's a broken loop. The app only works if it can rebuild that loop digitally.
The real problem moved from aggregation to confidence: building the social, musical, and contextual signal a person needs to decide quickly and trust the decision.
04Goal
Build a discovery experience that matches how underground culture actually works: social first, trust-led, music-forward. Validate it through a real launch in one city before scaling anywhere else.
The constraints that shaped it: side-project velocity, no formal PRD, a cold-start problem on day one, and a non-negotiable that nothing shipped that didn't feel native to the scene.
05Discovery
Three pieces of work, in sequence. Each one earned its place.
Audited Resident Advisor, Dice, Shotgun, and Facebook Events. Each solved a fragment. RA strong on listings, weak on curation. Dice good on personalised recommendations and notifications, lighter on social planning. Shotgun nailed spontaneity. Facebook owned coordination but felt culturally outdated in the spaces we cared about.
The white space wasn't more listings. It was the connective tissue between them: trust, music context, and lightweight planning in one place.
12 underground music fans across London, Toulouse, Sydney, and California. I led the interview structure around real behaviours – how they discovered, compared, planned, invited, attended – not stated preferences. A JTBD specialist joined after the first round and coached the team on framing jobs properly: what someone is actually trying to accomplish, not what they say they want. That shift changed which problems we thought we were solving.
The interviews collapsed into three findings:
Trust beats line-ups.
If a friend was going, people committed, even without recognising the artists.
Discovery is passive.
Most people weren't actively searching. If an event didn't surface through Instagram or a friend, it didn't exist.
Coordination kills momentum.
Planning moved into group chats, intent stayed fuzzy, and "maybe" quietly faded.
If my friends are going, I'll go even if I don't know the artist.
Interview participant, London
If I don't see it on Instagram, it's basically off my radar.
Interview participant, Sydney
We shared the event on WhatsApp but I didn't really know who was coming until the night.
Interview participant, Toulouse
The interviews surfaced the jobs. A ~200-respondent JTBD survey – incentivised with festival tickets to reach actual fans rather than survey completers – ranked them. The output was a graph plotting the most important jobs against how well existing tools were delivering on them. Trust signals and music context ranked highest. Algorithmic recommendation and browsing depth ranked lower.
That graph became the navigation blueprint. Features tied to high-priority, underserved jobs made the MVP. Everything else was deferred.
Jobs ranked by importance vs current satisfaction. The survey output that shaped the navigation and feature scope.
JTBD framing layered over interview clusters. How 12 conversations and ~200 survey responses collapsed into three findings.
06Design iterations
Before touching UI, I used Object-Oriented UX to map the ecosystem: users, events, artists, venues, mixes, places. Less requirements, more what exists and how do these things relate? Working through the objects let us agree the backbone fast: what an event page must carry, how social signals travel, where music belongs, what lives on an artist page versus a promoter page. It also forced scope decisions early – what the MVP needed versus what could wait.
The mental model that came out: discovery begins with events and people, supported by music. Not the other way around.
Around five participants on a clickable prototype tested each round. The goal wasn't polish. It was surfacing confusion fast.
V1, feed-led.
Home led with the feed: For You, Following, and Events in one tab. Search sat separately. The feed carried too many jobs at once, and Events got buried inside it rather than reading as a place to go.
V2, events-led.
Home led with Events, with Map reachable from the Events screen. Tapping Map dropped you into Search. That jump didn't land. Users didn't expect Map to become Search, and the path lost them.
V3, feeds and events split.
Home led with the Following and global feeds. Events broke out into its own prominent tab, with a toggle to switch into Map view. Discovery and feed stopped competing, and the Map lived where people went looking for somewhere to be.
I pushed for events to behave like posts in the feed: shareable, repostable, dynamic. That matched how people actually discover nights – through someone they follow putting an event in front of them, not through a search or a browse.
The call we made: finite scope, other features ranked higher against the JTBD priorities, and the interaction complexity of a social posting layer was too heavy to build and stabilise before launch. Events became the entry point in their own structured tab instead.
Six months later, we're reintroducing it. The logic is clearer now than it was then. With promoter and venue announcements sitting in a Following feed, a repost from someone you trust becomes the discovery signal – not an algorithmic push, but a person you've chosen vouching for a night. That was always the original instinct: people follow people, not platforms. The MVP couldn't afford the surface area. The product can now.
The original ambition was rich trust-based ranking: friends, followed artists, venues, taste overlap. Engineering pushed back: too heavy for MVP scope, and on day one there wouldn't be enough behavioural data for ranking to outperform a simple structural approach.
We held the line on structural discovery – Events, Map, follow-based signal – and parked personalisation until the data could carry it. We're building it now, six months in, with the behavioural data the structure earned.
↳Structure before screens
Objects mapped across the Kigs ecosystem. Blue for objects, yellow for core content, red for metadata.
↳Navigation wireframe iterations
V1. Feed-led home: For You, Following, and Events in one tab. Events got buried, feed carried too many jobs.
V2. Events-led home, Map reachable from the Events screen. Tapping Map dropped into Search — the jump didn't land for users.
V3. Following / Global feed. Events tab with a toggle to Map view. Search fully decoupled.
Search V1. A unified discovery surface: events, clubs, profiles, music, promoters, venues with filtering.
Search V2. Tab structure sharpened, filter states refined. Applicable to both navigation architectures.
07Solution
A map that earns its complexity gradually. The first instinct was a standard event map: pins, clusters, done. On a busy London weekend that map became a wall of markers with no way to read the room. The tension: legibility versus information density. Show everything and lose clarity. Hide everything and lose the point of a map. I worked through several clustering approaches with engineering before landing on progressive disclosure: light clusters zoomed out, attendance badges and date chips appearing only as you zoom in. You're not just picking a venue. You're joining a night with your people.
An event page that lets you audition the night. The tension: depth versus overload. A full DJ lineup with bios and tracklists would be accurate but paralysing. A name and a date wouldn't be enough. We landed on the lineup with set times, plus up to three mixes embedded directly from SoundCloud. Enough to get a feel for the night without leaving the page. Music context next to social proof is what moves someone from maybe to let's go.
Solving the cold start without waiting for users. The app only works if there's content on day one. We seeded the catalogue from live event data already circulating in the ecosystem, and integrated SoundCloud and Spotify so artist music surfaced automatically. Day one wasn't empty.
Home feed, Following tab, global Events list + Map view with friends-attending signal.
Event page top. Hero image, Going / Interested attendance, and the lineup with set times.
Event page bottom. Embedded SoundCloud mixes, "Going?" CTA, and activity feed showing who's attending.
Activity. Connection requests and followback.
Onboarding. Splash screen and explainer screens. Seeding the product value proposition from the first touchpoint.
Onboarding. Copy and layout revised.
Log-in screen. Minimal friction entry. The tone of the product set before the first tap.
Design system. Button components and type hierarchy.
Colour system. Primary palette and token definitions, extended states and semantic token mapping.
08Results
We launched in October 2025 around a live event on a canal boat in Toulouse, listed and promoted entirely inside Kigs. 150 users came in from that night. Local press picked it up. Within weeks, 500+ people had requested early access. Three months in: ~1,100 registered users, all organic, no paid acquisition.
La Belle Chaurienne. The canal boat venue in Toulouse.
Launch night. The crowd that came in from a single event listed entirely inside Kigs.
The crowd.
On the decks. No, we didn't hire Moby.
I've started checking Kigs when I'm not sure what to do on a weekend. I've already found a couple of events I wouldn't have come across otherwise.
Sandra, Toulouse
09Reflection
The retention gap is the brief. Day 2 says the product earns a return: people come back once. Day 7 says we haven't given them a reason to come back before something specific is happening.
The diagnosis: the home screen was showing everything. Promoter announcements, mix uploads, event listings from across the app. Volume without signal. Someone who follows three venues in London is getting noise from promoters they've never heard of on the other side of the world.
The response is now in build. Enrichment work has let us categorise events by genre and artist music the same way. Onboarding screens let new users follow pages, artists, and select genres from the start. The homepage is adapting: music matched to taste, events from people and places you've chosen to follow. Not a rebrand of the product. A recognition that the trust model only works if the feed respects what you've told it about yourself.
What I'd do differently. We built the first version on Draftbit, hit its limits, and the PM made the call to switch to Cursor mid-project. Right call for velocity and integrations. It also cost real time we couldn't afford on a part-time build. I'd commit to the stack earlier, even if it slows the first ship.
What I still don't know. Whether the trust-based model scales beyond cities where the underground scene is small enough that everyone knows everyone. London works because trust networks already exist. The harder test is a city where they don't.
Two things worth watching next. The first is friend-of-friend trust: soft-exposing second-degree attendance should lift event taps and saves, if the social layer is working the way the research said it would. The second is whether artist-linked journeys convert. If someone follows an artist and finds a night they're playing, does that chain hold all the way to the Going tap? That link is central to the product's thesis and we haven't measured it cleanly yet.
