Happenin
A local events app that discovered the hard part was venue supply, not the feed UI
Happenin was built for iOS in Social / Community. It died primarily from no distribution, but the useful signal is the 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.
No Distribution
What worked
What to avoid
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.
Timeline
The story
The useful part is not that it failed. It is where the founder saw signal, where the bet broke, and what a second builder should avoid.
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.
Failure analysis
Failure chain
- The problem was real: people wanted a better way to find local events.
- The first version relied on scraped and aggregated event supply.
- The event data decayed quickly and missed too many venue-specific events.
- Users opened the app, saw incomplete supply, and lost trust.
- The product needed manual venue relationships before it needed more software.
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.
Low revival potential because the core asset is not software; it is local supply acquisition.
Rebuild opportunity
3/10Rebuild thesis
A general local-events app is too broad for an indie builder. The viable revival is a narrow local media product: one city, one event category, curated deeply enough that users trust it more than social feeds.
Best operator fit
A local operator with venue relationships, newsletter discipline, or a small media background who enjoys sourcing events manually.
What to avoid repeating
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.
First 30-day revive plan
Pick one niche, publish a weekly manually curated guide, personally contact every relevant venue, and measure replies, saves, and shares before building software.
Major risks
Event data decays quickly, venue partnerships take time, monetization starts small, and expanding categories can dilute the trust that made the niche work.
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 GraveyardYour message is reviewed by App Graveyard first. Founder emails are never shown publicly.Open form
Turn this postmortem into a pre-flight check.
The product may be useful, but there is no repeatable path to reach the right buyers.
Related postmortems
SkillSwap
A skill-barter marketplace that ran into the double-coincidence problem immediately
RankBoost
An indie ASO tool whose ranking data broke when Apple shifted the ground underneath it
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.