Happenin
Find what's happening tonight in your city — concerts, pop-ups, open mics, and more
Treating an event supply problem as a tech problem. I spent 80% of my time building scrapers, aggregation logic, and a nice UI. I spent 20% on actually sourcing events. It should have been the reverse. The tech was the easy part — building a nice feed took 2 weeks. Filling the feed with comprehensive, accurate event data for even one city was an unsolved problem that required manual outreach, partnerships with venues, and a content operation. I was a developer building a product that needed a sales team.
3/10 revival potential
Timeline
The story
What was built
Happenin was a local events app for my city (Austin). It aggregated events from multiple sources — venue websites, Facebook Events, Eventbrite, Instagram posts from bars and venues — into one feed organized by tonight, this weekend, and this week. Users could filter by type (music, food, comedy, art, outdoors, nightlife), save events, and share them with friends. I also built a 'surprise me' feature that picked a random event for tonight. The idea was to be the definitive 'what's happening' guide that replaced Googling, checking Instagram, and scrolling Facebook Events.
Why they built it
Every Friday night, my friends and I would spend 30 minutes in a group chat trying to figure out what to do. Someone would check Instagram, someone would check Facebook Events, someone would Google 'live music Austin tonight.' It was scattered and inefficient. I assumed there should be one app that shows everything happening in your city. I figured if I could aggregate all the events, the demand would come naturally because the problem was obvious and universal.
What worked
The UX was good. The 'tonight' feed with category filters was clean and fast. People who used it during SXSW week (when I happened to have good event coverage) said it was the best way to find things to do. The 'surprise me' button was fun and people shared screenshots of random events with friends. A few Austin food bloggers shared the app, which drove my best download days.
What failed
I could not keep the event data fresh. This was the fundamental problem and I underestimated it by an order of magnitude. Most local events aren't on Eventbrite or Facebook Events. They're announced on Instagram stories, printed flyers in coffee shops, word of mouth, or venue-specific websites with no structured data. Scraping was fragile and missed most events. I tried building a submission form for venue owners, but getting venues to submit events was a full-time sales job — I'd email 30 venues and get 2 responses. At any given time, my app showed maybe 15-25 events for a city with hundreds happening nightly. Users opened the app, saw a thin list that missed obvious things their friends were going to, and closed it. A sparse events app is worse than no app because it implies nothing is happening.
What was validated
The UX was good. The 'tonight' feed with category filters was clean and fast. People who used it during SXSW week (when I happened to have good event coverage) said it was the best way to find things to do. The 'surprise me' button was fun and people shared screenshots of random events with friends. A few Austin food bloggers shared the app, which drove my best download days.
Key lesson
Treating an event supply problem as a tech problem. I spent 80% of my time building scrapers, aggregation logic, and a nice UI. I spent 20% on actually sourcing events. It should have been the reverse. The tech was the easy part — building a nice feed took 2 weeks. Filling the feed with comprehensive, accurate event data for even one city was an unsolved problem that required manual outreach, partnerships with venues, and a content operation. I was a developer building a product that needed a sales team.
Failure analysis
What the signals looked like
The UX was good. The 'tonight' feed with category filters was clean and fast. People who used it during SXSW week (when I happened to have good event coverage) said it was the best way to find things to do. The 'surprise me' button was fun and people shared screenshots of random events with friends. A few Austin food bloggers shared the app, which drove my best download days.
Where it actually broke
I could not keep the event data fresh. This was the fundamental problem and I underestimated it by an order of magnitude. Most local events aren't on Eventbrite or Facebook Events. They're announced on Instagram stories, printed flyers in coffee shops, word of mouth, or venue-specific websites with no structured data. Scraping was fragile and missed most events. I tried building a submission form for venue owners, but getting venues to submit events was a full-time sales job — I'd email 30 venues and get 2 responses. At any given time, my app showed maybe 15-25 events for a city with hundreds happening nightly. Users opened the app, saw a thin list that missed obvious things their friends were going to, and closed it. A sparse events app is worse than no app because it implies nothing is happening.
Lessons
What the founder learned
Local content businesses (events, restaurant reviews, neighborhood guides) are supply-constrained, not tech-constrained. The app is the easy part. The database of accurate, fresh, comprehensive local information is the hard part, and it's a manual, relationship-driven operation. Yelp, Google Maps, and local media companies solved this with armies of salespeople, not better software. If you're a solo developer building a local content product, you are fundamentally mismatched with the problem — the job is 80% sales/partnerships and 20% code. Also, 'aggregating existing sources' sounds scalable but isn't. Most valuable local information doesn't exist in structured, scrapable formats. It's in Instagram stories, word of mouth, and paper flyers.
What they’d do differently
I wouldn't build a general events app. Instead, I'd focus on one narrow vertical in one city — like 'open mics in Austin' or 'pop-up food events in Austin' — where I could personally know every venue and maintain a complete, accurate listing. Start as a curated newsletter or Instagram account (zero tech needed), build an audience, and only build an app once I had the content supply problem solved manually. The app should be the last thing built, not the first.
Editorial scorecard
How viable is rebuilding this today?
Did real users or customers want this?
How well was it built and shipped?
Did they have a path to reach users?
Was the business model viable?
How useful is this postmortem for other builders?
Scores are assigned by App Graveyard editors after review. They are directional, not scientific.
Rebuild opportunity
3/10General 'local events' apps are nearly impossible for indie builders because of the supply problem. But hyper-niche event discovery (one city, one event type, curated by a local expert) can work as a content brand first, tech product second. A 'live jazz in Brooklyn' newsletter with an accompanying simple website could become the definitive source because the scope is small enough for one person to cover completely. Scale is the enemy here — go narrow and deep.
Revive this app
The founder is open to revival interest. App Graveyard has not verified ownership, asset claims, pricing, or availability yet. This is an interest signal, not a transaction.
Contact through App Graveyard
We review revival interest before anything is forwarded. The founder's private contact details are never shown publicly.
Related postmortems
Built something that didn't work out?
Every failed app has a lesson. Submit yours and help the next builder avoid your mistake. Anonymous submissions welcome.