Bike Bus

Every bike bus starts the same way: a WhatsApp group, one keen parent, and a great idea. Then real life gets in the way.

The lead parent takes a sick day, gets stuck in traffic, or goes on holiday — and the whole thing quietly stalls. Nobody wants to be the one standing on the corner in the rain, waiting for a ride that was cancelled at 7:41am and buried under forty other messages about the school fair.

The usual workaround makes it worse. Someone shares a mobile number or an email so people can "just message directly" — and hands it to a group that keeps growing every term. It doesn't take long before that becomes a spam magnet, or something less innocent.

The problem was never enthusiasm. It was that the whole system depended on one person being available, awake, and glued to their phone, every single morning.

So the fix wasn't a better leader. It was removing the idea of a leader altogether.

Bike Bus behaves like a flock rather than a chain of command. Any parent in the group can open the app and tap Start Ride — there's no admin, no gatekeeper, no single point of failure. Whoever gets there first switches on a live beacon, and the ride exists from that moment, for everyone.

Getting the notifications right mattered more than the map itself. Nobody wants their kid standing on a cold corner ten minutes early, and nobody wants them to miss the bus because they weren't staring at their phone. So there are two triggers, not one:

• —First Beacon Active — the moment someone starts a ride, everyone still at home gets a nudge. No more guessing whether today's the day.
• —500m Proximity Alert — when the beacon gets close, the next family gets pinged. Not before, not vaguely — close enough that stepping outside actually means something.

Two notifications, timed right, and nobody's standing in the rain for nothing.

The moment you're building something that tracks children's location, the brief changes. This isn't a feature to get right — it's the whole product, and there's no version of "close enough" that's acceptable here.

The first decision was to make the data disappear. Location is only ever live during an active ride, and it's automatically destroyed 60 minutes after that ride ends. There's no archive of where anyone's kid was three Tuesdays ago, because that archive is a liability nobody needs and no parent asked for.

The second decision was harder to justify on a whiteboard but obvious in practice: access to a bus is granted entirely through the WhatsApp groups parents already use to organise the school run. No public sign-up, no searchable directory, no stranger requesting to join. If you're already in the group, you're already vetted by the parents who built it. The social layer does the security work, so the app doesn't need a heavy permissions system bolted on top.

It's not the most sophisticated security model on paper. But it matches how trust actually works at a school gate, and it meant I could keep the app simple instead of asking parents to manage settings they'd never touch.