Product / 0 to 1 / Technology

Nightlife Discovery Platform

I killed my original product idea after the research told me I was solving the wrong problem.

Building a consumer nightlife product from discovery toward launch.

A nightlife discovery product built from 21 interviews, a strategic pivot, and a multi-sided marketplace model.

Placeholder

Hypothesis to pivot

Future diagram with approved interface screenshots inside it

Role: Founder and Product Lead

Timeline: Jan 2026–present

Location: Raleigh / Triangle

Status: Pre-launch

Proof points

0→1 product development21 user interviews3 user segmentsAgentic research systemMulti-sided marketplace data modelLed 3-engineer build team

Case study path

Hypothesis

Research

Contradiction

Pivot

Wedge

Product

Validation

The Market

Nightlife discovery and distribution are fragmented across fans, DJs, organizers, and venues.

What's happening on a given night is spread across Instagram, venue pages, ticketing platforms, promoter channels, DJ profiles, and word of mouth. No single place answers the question a fan actually has:

What's happening tonight that I would actually want to go to?

The same fragmentation works in the other direction. DJs and organizers struggle to reach the people most likely to care about their events. For early-career DJs, their public record is scattered across posts, mixes, and informal press kits, making it difficult for someone outside their network to evaluate them.

That is the ecosystem the product entered. The first bet focused on one part of it.

The Original Bet

The first hypothesis was a B2B booking marketplace, written out in full before the first interview:

Early-to-mid career DJs in smaller nightlife markets lack a credible, structured way to present themselves to venues. Venues would actively use a platform that aggregates performance history, full set recordings, and venue-verified credentials, because it reduces their research time and surfaces talent outside their network. DJs will maintain profiles in exchange for real booking opportunities, and the resulting transaction data becomes a verified credibility layer competitors cannot easily replicate.

It was a reasonable hypothesis, and an untested one. The next step was to find out whether it held.

Discovery System

Research system workflow showing interviews becoming tagged evidence, updated assumptions, warning flags, decisions, and the next interview. — Explore the Research System →

I designed the research to test the hypothesis, not confirm it.

The interviews ran through a human-directed research system I built. It did more than summarize conversations. Across sessions it carried the evidence gathered so far, the assumptions behind the product, the confidence in each, and the open questions still to test.

Behavioral evidence outweighed stated problems. Original assumptions were preserved, never rewritten, so the record showed how beliefs changed.

The system was built to find disconfirming signals. It could warn when an assumption was weakening, when there wasn't yet enough evidence to call something a pattern, and when new evidence contradicted the current product hypothesis.

The research reached 21 interviews: 12 DJs, 7 event organizers, and 2 venue-side participants.

The Contradiction

THE SIGNAL DIDN'T MATCH THE MODEL.

These were early signals, several from a single source, and the research recorded them at that confidence.

Two interviews in, the system raised a warning:

THE PRODUCT MAY BE POINTED AT THE WRONG DEMAND SIDE.

That warning did not recommend going fan-first. At that stage the evidence suggested organizers were a demand side worth investigating, and the open question was narrow: is this a DJ-to-venue platform or a DJ-to-organizer platform?

The fan-first strategy came later, after I weighed the research as a whole.

The Pivot

I changed the sequencing, not the market.

Instead of starting with venues, the product starts with fans: a way to see who is playing, where, and when. DJs, venues, and organizers get free reach first and claim their presence once there are fans to reach.

The research system surfaced the evidence and the warnings. What they meant, and what to build instead, was my decision.

Before

Venue-first marketplace

The original bet was that venues needed a better way to discover and evaluate DJs.

Signal

Demand was forming elsewhere

Interviews challenged the original demand-side assumption before the booking product was built.

After

Fan-first discovery

Build the audience layer first, then return to booking after demand behavior is clearer.

21 interviews3 user segmentsMarketplace thesis challengedFan-first wedge prioritized

Designing the Wedge

The fan-first product doesn't abandon the marketplace opportunity. It is the way into it.

The supply side still matters, but a supply-side product needs leverage. In nightlife, the leverage is an audience.

Fans come for discovery. Discovery builds an audience. An audience is what makes the platform worth something to DJs, organizers, and venues. Booking becomes viable once those relationships exist on the platform.

The wedge is discovery. The longer-term opportunity is the network around it.

Key Product Choices

Browse before signup. Fans can use the feed without creating an account. Why: a new discovery product has to show value before it can ask for commitment. Tradeoff: less user data early, and a harder path to notifications and personalization.

Seed before claiming. The team seeds events and profiles as placeholders. DJs, venues, and organizers claim them later, with verification for organizers. Why: research challenged whether DJs would build profiles and suggested adoption follows visible social proof. Placeholder profiles mean nobody has to do work before the platform is worth their time, and early claimers see peers already listed. Tradeoff: seeding is manual and does not scale, and the gap between claimed and unclaimed profiles has to be managed.

Booking comes later. Raleigh first. Booking and monetization follow once audience and supply-side value are demonstrated. Booking is already modeled in the data layer, so it can return without a rebuild. Tradeoff: the product runs at a cost with no revenue during validation.

Building the System

I lead product direction and designed the underlying data model. It was built for the longer-term multi-sided opportunity, not just the first release. Fans, DJs, organizers, venues, claiming, and booking are all modeled now, so later phases extend the system instead of replacing it.

The decision log records each major product decision with the evidence behind it.

The Product

For fans: set genre preferences and get a curated feed of who is playing, where, and when. Follow DJs across venues. Save events. Get notified.

For DJs: a fan-facing profile that follows them from venue to venue.

For venues and organizers: free reach to an audience first, then a claimed, verified presence once that audience exists.

010

Where It Stands

The research showed the original plan was the wrong first step. It has not shown the new plan is right. That is what launch is for.

SHIPPING PROVES WE CAN BUILD IT.

USAGE WILL TELL US WHETHER WE'RE RIGHT.