Case Study
Luzit — A Social Event Platform for Israel’s Gay Community
A complex two-sided product:
- Role-based user types with distinct toolsets
- Partial gating with guest access
- Content moderation with anti-enumeration patterns
- Push notifications
- Deep linking
- A privacy model designed for a community where visibility carries real risk
Built across three iterations — most recently solo (V2), with AI-assisted development that pushed me to go deep on system design, backend architecture, and modern frameworks rather than treat AI as a shortcut.
The problem nobody was solving
Israel’s gay community runs on events. Around 100 happen every month — drag shows, hiking groups, support circles, dinners, parties, fitness meetups, medical checkups. But there was no shared place to find them.
Events lived scattered across Instagram posts, Facebook groups, WhatsApp broadcasts, organizer websites, and one ticketing site that only covered parties. None of these platforms were built for event discovery — events disappeared into general feeds alongside unrelated content, with no calendar view, no chronological sort, no way to filter. To find what was happening this weekend, you had to already know which organizers to follow, which groups to join, which channels to scroll. If you didn’t, you didn’t know.
The community had supply. It had demand. What it was missing was the layer in between.
Why this audience needed its own product
I spent the discovery phase interviewing around 25 organizers (organizations, businesses, individual hosts) and 30 community members. Two patterns came up repeatedly that no generic event app handles well:
Privacy isn’t optional.Some users are out to their friends but not their families, employers, or the broader internet. RSVPing to an event can’t be a public broadcast by default — but social proof is also part of why people come. Toggleable visibility wasn’t a nice-to-have, it was the design.
Trust is a feature. Community organizations want their events surrounded by other community events, not buried in a generic feed next to weddings and corporate networking. They wanted the safety of a dedicated space — for themselves and for the people they serve.
That second insight is what convinced me this was a product, not a feature inside an existing platform.
The decisions that shaped the product
Luzit serves two audiences with very different jobs: participants discovering events, and organizers running them. The app branches at signup into two account types, each with its own profile structure, social fields, and feature set. Most of the decisions below trace back to that split.
Pivot: Organizers don’t post from their phones
The most important thing I learned from organizer interviews wasn’t a feature request. It was a workflow.
Every organizer described the same routine: they prepare event content on their laptop — image files in their downloads folder, text drafts in a doc, copy and paste across multiple browser tabs — and only then push it out to mobile to share in WhatsApp groups. They also tend to post in chunks, adding several events at once. The friction wasn’t event creation. It was the device mismatch.
Luzit’s first version was mobile-only. That was wrong. Organizers were the supply side of a two-sided marketplace, and I’d built them the worst tool for the job.
I designed a web interface for event creation and editing while keeping discovery mobile-first for participants. This was the right product decision but the wrong technical bet — we were on Flutter, which we discovered performed poorly on web as opposed to its premise (my co-founder was an inexperienced developer). The cost of correcting it was a full rebuild in React, and that rebuild ultimately took the partnership down with it.
Lesson: technology choice is a product decision. I now scope feasibility before committing to platforms, not after.
Privacy as interlocking systems
Privacy in Luzit isn’t one feature. It runs system-wide:
- RSVP privacy mode— participants can mark themselves as attending and be visible only to the host. Other users see them as an anonymous placeholder, counted but not named. Their public profile won’t show that RSVP either.
- Guest gating on the attendee list— even with public RSVPs, unauthenticated visitors never see who’s attending. This protects registered users from being scraped or surveilled by anyone outside the community.
- Content moderation aligned to community guidelines — events that violate community standards (abusive, explicitly sexual, off-mission) are hidden from the calendar, with the option for the owner to edit and resubmit.
App store policy was the trigger for some of this work, but the design came from the community. Closeted users, hostile outsiders, and bad-faith content are all real threats to community trust. One layer wasn’t enough.
Organizer profiles as community landing pages
In interviews, organizers kept describing the same external workaround: they used Linktree, built basic websites, or leaned on social apps just to host their event schedule, services, and contact info in one place — each providing only a partial solution to their needs. Most of those tools weren’t built for events. They were link aggregators with calendar-shaped holes in them.
I designed organizer profiles to fill that hole:
- A unique URL that can replace their existing landing page (customizable username)
- Business info (bio, services, social links — Instagram, WhatsApp, website, phone)
- An agenda-style list of all their hosted events that updates automatically
- Display of event types they host
The participant profile is deliberately different:
- RSVPed events
- Fewer social fields
- Display of event types the user is interested in
Same app, two products under the hood.
Removing the gate
V2 initially required signup before browsing. I’d argued for this on exclusivity and safety grounds for the gay community, especially given the planned addition of social features (RSVP, attendee lists), and partly because most community and event apps are gated — Meetup, Facebook Events, Instagram all require an account.
After interviewing 30 community members, every single one pushed back: they wanted to evaluate the product before committing. They were used to it from Chillz, the parties site they already trusted.
But I wasn’t deciding from 30 conversations alone. The first two launches had used partial gating — participants browsed freely, organizers signed up to post — and that model had reached 1,500 MAU. The data said open it up. I removed the signup wall before public launch.
When execution became the bottleneck
A major, well-known organization in Israel’s gay community — running about 35 events a month — agreed to a partnership. Their condition was specific: ship a customizable shareable profile with a unique username link, plus bio and social links. The agenda view of their events was already in the product; these additions would let their Luzit profile fully replace the basic landing page service they were currently paying for.
This would have solved Luzit’s biggest problem (event supply) and brought network effects with it — once a flagship organization joins, others follow.
The features didn’t ship in time. My co-founder couldn’t deliver, the org turned to a more basic alternative, and I lost the partnership and the supply it represented.
That’s the moment I understood that being right about the roadmap doesn’t matter if you can’t execute it. Both of my technical partnerships failed for the same structural reason: junior developers building Luzit as a side project to their day jobs, with neither the time nor the experience to deliver at the pace a two-sided marketplace requires. After the second one ended, I stopped looking for another developer and rebuilt V2 myself with AI-assisted development. The current version ships features I’d wanted for three years: push notifications, deep linking, role-based admin tools, content moderation, and a full web app at luzit.gay.
What I’d track next
The current version is live in both app stores and pre-marketing. The metrics I’m setting up to watch:
- Conversion: % of guests who sign up, and % of new signups who RSVP within 7 days (RSVP is the main activation trigger)
- Supply health: weekly organic event posts (not scraped), targeting 8/week within two months
- Retention: Week-2 and Week-4 return rates, segmented by participant vs. organizer
- Network effects: % of users arriving via shared event or profile links
Earlier launches reached around 1,500 MAU and 700 organic downloads in the first 3 hours after a single Facebook post — encouraging signal for word-of-mouth in this niche, but I want sharper retention data this round before declaring product-market fit.
What I learned
- User research compounds.Three iterations of market knowledge are what’s letting me build the right thing now, faster, with fewer people.
- A feature shipped late is a feature that didn’t exist. Lean PRDs first, iterate after validation.
- Co-founder choice is a product decision. Both of my partnerships failed because the developers were juniors with Luzit as a side project — not enough hours, not enough experience, not enough urgency. Removing that bottleneck (even by becoming the developer myself) was the unlock.
- Building for a community means designing for trust, not just utility. Privacy, moderation, and guest gating aren’t compliance work. They’re the product.