We built the app we needed for our own Thursday game.

The problem that started it

Jum started with one community running one weekly futsal game, entirely through a WhatsApp group and a lot of memory. Someone would ask "who's in this week?" and count replies by hand. The organiser tracked the growing list, split people into teams close to kickoff, and — after the game — tried to remember who'd fronted the pitch fee and who still owed for it. Every week, the same manual cycle, repeated from scratch.

None of that is a WhatsApp problem specifically. A chat log was never built to be a system of record — it's just really good at looking like one, right up until someone asks "wait, did I already pay for this?"

What we believe

Organising a recurring game is real work, and it's almost always done by one person, unpaid, out of goodwill. We think the tools around that work should respect it — not add another app to check, but remove the parts that were never fun to do by hand in the first place: counting RSVPs, splitting teams fairly, and chasing money.

We also think this problem isn't unique to one group or one sport. Any recurring paid activity with a rotating cast — a five-a-side crew, a running club, a badminton group, a monthly board game night — runs into the exact same friction. So Jum is being built to work for any community running that pattern, not just the one it started with.

Where it's headed

Jum is being built as a proper multi-tenant product from day one — any organiser can create and run their own community, not just the group it was first built for. It's currently in private testing with real communities ahead of a public launch; see the Get Jum panel on the homepage for where that stands right now.