The 20-Minute Plan

Inspiration

Track 2 — Connect Outside — asks a pretty direct question: how do we make it easier for people to step beyond their routines and experience more joy together? The track brief itself names "the sheer effort of organising plans" as a real barrier, and that line matched something all of us have lived through more times than we'd like to admit: a group chat with four people, forty messages, three "idk what do you guys wanna do"s, and a plan that either dies entirely or gets decided by whoever gets tired of waiting first. The idea behind the app came directly from that — the problem was never a lack of things to do nearby, it was the friction of getting a group to actually land on one.

What it does

You start a session and get a 4-letter code. Up to three friends join with that code on their own phones. Everyone answers three quick prompts privately — nobody sees anyone else's answers — covering energy (loud/quiet), how far they'll go, and budget. The moment everyone's answered, the app resolves all of it into one plan and reveals it to every phone in the session at the same time: a real nearby activity, a one-line reason it fits, and a map link.

If the group's answers don't have one activity that satisfies everyone, the app doesn't just fail silently — it picks the closest fit and says so honestly ("everyone agreed except budget — this one runs a little over"). It also factors in a fourth, optional prompt for accessibility needs (step-free access, low-noise environments, no-alcohol venues), and adjusts the recommendation if the plan it would've picked doesn't hold up against current weather — swapping an outdoor pick for an indoor one and explaining why.

How we built it

The whole thing runs on a single Node.js process — Express serving the frontend, a ws WebSocket server handling the realtime session/lobby/answer flow, and no external services or API keys required. That was a deliberate call, not a default: hackathon wifi is one of the most common reasons a live demo breaks, so we kept the entire multiplayer experience self-hosted rather than depending on a third-party realtime backend.

The matching logic is a small scoring engine (lib/matching.js) that checks every activity in our curated dataset against every group member's answers across three dimensions, and always returns something — there's no "no results" state, only a full match or an honest closest fit. The dataset itself is ~18 hand-written entries, each tagged for energy, distance, budget, indoor/outdoor, and accessibility fit, rather than pulled live from a places API — we traded breadth for reliability and quality of copy on demo day.

The frontend is vanilla HTML/CSS/JS — five screens (start, lobby, prompts, converge, plan reveal), a light color theme built around a warm off-white background and an amber "decision" accent, and a small choreographed entrance animation on the homepage so the first thing you see feels like the product, not a form.

Challenges we ran into

Getting the matching algorithm to fail gracefully took more thought than getting it to work in the happy-path case — a group with genuinely conflicting answers needs a result that still feels honest and useful, not a broken or empty screen. We landed on always surfacing the closest fit and naming exactly which constraint got relaxed, rather than hiding that from the group.

We also had to be disciplined about scope. It would've been easy to keep adding features — cost splitting, saved friend groups, live booking — and we made a deliberate call partway through to cap new features at two (weather-aware fallback and accessibility constraints) rather than spreading thin across four, because a smaller set of things that work reliably beats a longer feature list that's shaky under pressure.

[FILL IN — your real Saturday mentor check-in]: One piece of feedback we got from our mentor was ___, which led us to change _, because ____.

Accomplishments that we're proud of

We tested the core multiplayer flow end-to-end before considering it done — two real clients creating a session, joining, answering privately, and both receiving the exact same resolved plan at the same moment, with no manual babysitting required. We also built a fully offline "solo demo" fallback mode into the app itself, so even with zero network the whole flow — including the weather-aware fallback — can be demonstrated from one laptop. That felt like the right kind of ambition for a hackathon demo: not the flashiest possible feature, but genuinely not being able to fail on stage.

[FILL IN — how the live demo actually went / any moment that got a laugh or a genuine reaction]

What we learned

The biggest lesson was that "what happens when it doesn't work perfectly" is often more important to design than the happy path — our closest-fit fallback, our weather override, and our offline demo mode all exist because we asked "what's the ugly case" before we asked "what's the ideal case." We also learned that constraint matters more than we expected: capping ourselves to two new features instead of four made the two we shipped noticeably more solid than if we'd spread across all of them.

What's next for The 20-Minute Plan Real booking integration — right now "go" opens Maps or a share sheet; a real version would deep-link into actual venue booking/ticketing where available. A live places dataset — our curated 18-entry list works for one city; scaling this means layering in a real places API once the core format is validated, without losing the hand-picked quality of the copy. Group memory — recognising a friend group that's used the app before, without requiring accounts or logins. Mid-session disconnect handling — right now, someone dropping mid-session is treated as final; a real version would support reconnecting. Cost-splitting — a rough per-person estimate on the plan card, not just a budget filter going in.

Built With

• css3
• express.js
• google
• html5
• javascript
• json
• maps
• node.js
• npm
• websocket
• ws