Why we built Happening

Dr Marcus Judge, CEO of Happening · · 5 min read

A few years ago I sat in a group chat with my oldest friends, all of us doctors, trying to pick a date for a party. One of us had floated the idea that morning. Nothing fancy, just a night in a flat with drinks and music and people we hadn't seen properly in months.

Forty-five minutes later we were still going. Saturdays kept getting ruled out for nights on call. Weeknights were out because of early starts. Whole weekends disappeared into rota swaps, family commitments and "actually I'm away that month". We worked through the next four months, week by week, and eventually admitted what had been obvious for twenty minutes. There was no date. Not one. The chat went quiet. The party never happened.

I sat on my sofa at the end of it feeling stressed, slightly embarrassed, and genuinely sad. We hadn't fallen out. We hadn't stopped wanting to see each other. We had just lost 45 minutes of our evening to a coordination problem that nobody in the chat could solve on their own, because the information we needed was scattered across six people's heads and six people's calendars.

That was the evening I started thinking about Happening. Not as a product. Just as the thing I wished had existed when someone first said "let's have a party".

Why group chats fail at this

Group chats are built for conversation. They are not built for coordination. When six people start throwing out possible dates, the information you actually care about, which is who can make which day, ends up scattered across half-replies. "Yeah the 14th could work." "Not the weekend after, I'm in Leeds." "Wait, was that this Saturday or next?" Every new message buries the answer a bit further. By the time anyone tries to pull it all together, three people have stopped reading.

The honest answer to "why didn't you just use Doodle?" is that Doodle was built for meetings. It assumes you already know exactly who needs to be involved, that everyone will fill in a poll within a week, and that the output is a single time slot. It is excellent at what it does, and completely wrong for the low-stakes coordination that friend groups actually need.

What friend groups need is closer to a shared view of "when I'm broadly free". Not a commitment to 7pm on Tuesday the 14th. Just: this weekend is open, that weekend is not. You don't need to RSVP. You don't need to know who is organising what. You just need to be visible to the friend trying to pick a date.

The first version was a spreadsheet

Embarrassingly, the first version of Happening was a Google Sheet. One row per person, one column per date, green for free, red for busy. It worked, in the sense that we organised three dinners with it in the first month. But it had two obvious problems. Everyone had to remember to open it, which meant half the group never did. And it was ugly enough that we could only really foist it on people who already liked us.

So I started building. The rule I wrote for myself was simple. It should take less effort to use Happening than to send one message in a group chat. If at any point a user has to ask themselves "is this worth the friction?", we have already lost them.

The rules we would not break

Three rules shaped everything.

  1. No accounts for guests. If a friend invites you to mark your availability, you should not have to sign up for anything. Click the link, tap the dates you can do, done. Friction kills group coordination.
  2. No notifications you didn't ask for. Group chats are loud. Happening is quiet. We notify you when something genuinely needs your attention, like a new invite or a date being confirmed, and never for "X just opened the app".
  3. The host shouldn't have to chase. The whole point is to take the cognitive load off the organiser. If the host has to keep nudging people to respond, we have just rebuilt the group chat with extra steps.

What we deliberately left out

Every beta tester asked for something different. Recurring events, voting on locations, integration with their work calendar, a chat feature, polls inside the app. Each suggestion was reasonable in isolation. Each one would have turned Happening into a worse version of something that already existed.

So we said no, a lot. Happening v1 ships with one job. Find a date that works for everyone, with the least possible friction. Locations, agendas, who brings the wine: those belong in the actual conversation that starts once you have a date. We are not trying to replace that conversation. We just want to get you to it faster.

What is next

v1 is live. The core loop works. Hosts create events, friends tap their availability, the app ranks the dates that work for the most people, the host picks one. That is the whole product, and getting a date booked now takes under a minute.

Whether it stays this simple is up to the people who use it. We have a list of things we will consider, but every item has to clear the same bar: does this make the core loop easier, or does it just add weight? If it adds weight, it doesn't ship.

Thank you for being here at the start. If Happening helps you rescue one party that would otherwise have died in a group chat, the whole thing was worth building. I am still thinking about the one we lost.

← Back to all posts