Game Night: How a Side Project Ended Up With 150,000 Installs

I didn't set out to build a drinking game app. I set out to have something to show for a weekend.

That's the honest version of how Game Night started. It was a side project, built fast, with a premise so simple I almost didn't think it was worth finishing: a digital drinking game for groups. Tap to spin. Everyone drinks. That's the whole thing.

I shipped it anyway. Somewhere between that weekend and today, it crossed 150,000 installs.

Here's what I actually learned.

The Premise Did the Work

The hardest problem in indie mobile development is usually distribution. You build something, you post it, and then — nothing. The product sits in the store and you try to figure out how to get anyone to see it.

Game Night didn't have that problem, at least not at the same scale, because the use case built distribution in. You play it in a group. Someone in the group doesn't have it. They install it. The next time they're at a different party, they show someone else.

I didn't design this in. It just happened because the use case was inherently social. But looking back, that's the thing I'd be most intentional about if I were starting over: not "what does this product do" but "in what situation does someone hand their phone to another person?"

Game Night had an answer. Most of my other products don't.

The Numbers That Surprised Me

150,000 installs sounds like a milestone. It is, kind of. But the number I look at more is the 4.5-star rating across several thousand reviews — because that's not something you game or buy. That's people having a good time and then going back to rate it at the end of the night.

What surprised me most: the retention curve. Drinking games are intrinsically event-driven — someone downloads it before a party, uses it once or twice, then it sits. I expected high churn. Instead, I saw users coming back months later, reinstalling before events, sharing the link in group chats.

The app isn't sticky in the traditional sense. But it became useful at a specific moment, and that moment repeats. That's a different kind of retention than I was used to thinking about.

What I Got Wrong Early

I spent too much time adding features nobody asked for and not enough time on the core loop.

In the first year, I added themed packs, custom game modes, a "create your own" flow. None of them moved the needle. The reviews that came in were still about the basic experience: "simple, works, had a great time."

The product I built in a weekend was already the product people wanted. I just didn't trust that for about 18 months.

The lesson I keep having to relearn: when users are happy with what you built, don't fix it. When they're not, figure out the actual problem before adding anything.

What I'd Do Differently

One thing: I'd have documented the growth as it happened. Not for an audience — just for myself. I have a rough mental model of how Game Night grew, what worked, what didn't, but I don't have the actual data from the early days. I wasn't running analytics the way I should have been, partly because I didn't expect it to go anywhere.

If you're building something and it starts working, start writing things down. Not a postmortem — just a running log. You'll want it later.

What It Means for XenneX

Game Night is one of six live products I'm running through XenneX. It generates revenue, it has an audience, and it mostly runs itself at this point. That matters a lot in a multi-product studio — you need some things to be stable so you have room to take risks on others.

150,000 installs didn't change my life. But it validated something I wasn't sure about when I started: that you can build something small, simple, and genuinely useful, and if the timing and the premise are right, people will find it.

That's still the model. That's still why I keep building.