Event Board
A two-week build to solve a problem I kept living
I love planning events — it's genuinely one of my things. So when a friend announced she was moving countries and we decided to throw her a farewell party, I was already thinking about how to make it work.
And so the familiar chaos began. A WhatsApp thread that starts with "when is everyone free?" and slowly becomes something nobody can navigate. Dates proposed and buried under memes. Someone pins the location. Someone else pins the time. Three days later someone asks what time it starts. We end up typing the same information into the event description, the chat, a note somewhere — and still someone doesn't know who's bringing what.
WhatsApp has polls and events — but polls get buried in the thread and events only capture what's already decided. There's no working layer in between, where the group figures things out before anything is final. And expenses? Always an afterthought — a screenshot, some mental math, an awkward ask a week later.
I wanted to build that missing layer.
What it is
Event Board is a lightweight planning tool for small friend groups. Everyone joins via a shared link — no app download, no account creation friction. Inside, the group can vote on decisions, claim tasks, and log expenses. WhatsApp stays for the banter. Event Board holds the things that actually need to be remembered.
How I built it
I used Claude for product thinking and Cursor for implementation — a workflow that let me focus energy on the decisions that actually mattered: what the app should do, how it should behave, and why.
I documented the design decisions during the build. Not as an exercise — but because I kept hitting forks in the road and wanted to be honest with myself about why I went one way and not the other.
Few of those decisions are worth sharing here.
"Decisions" not Polls
The original wireframe used the word Polls. It felt natural — you're asking a group to vote, that's a poll.
But WhatsApp already has polls, and they get buried. The problem isn't the mechanism — it's that there's nowhere to see all your open questions in one place, lock them when the group is ready, and connect them to everything else about the event.
Renaming to Decisions also shifted the mental model. Polls implies something ongoing. Decisions implies resolution — this thing has a conclusion, not just a participation count. And when a decision is locked, the winning option is visually highlighted. It transforms from "voting disabled" to "this is what we're doing."
Manual Lock over auto-lock
The obvious implementation: once everyone votes, the decision locks automatically.
The problem: late joiners. If someone joins the event after voting is "complete," they can't participate. Worse, auto-lock assumes voting percentage equals consensus — but in friend groups, silence isn't the same as agreement.
The solution: the event creator locks manually when the group feels ready. It mirrors how real decisions happen — not by algorithm, but by someone reading the room and calling it.
Self ownership over assigned tasks
I initially thought of tasks as a to-do list — organizer creates items, assigns them to people. Clean, logical, top-down.
But that's not how favors work among friends. Nobody wants to be voluntold. The self-assign model — where the organizer creates unassigned tasks and participants claim them by tapping "I'll do this" — mirrors a signup sheet. Voluntary commitment. People follow through more on things they chose.
That reframe changed how the whole feature felt.
When prototype meets reality
I started with localStorage for user identity — no login required, your name saved in your browser. Simple, low-friction, good enough to test the concept.
Real testing ended that quickly. A family member opened the link on a different device and couldn't see their tasks from their laptop. Cross-device sync wasn't an edge case — it was the whole point of a shared group tool.
Google authentication was on the v2 roadmap. It moved to v1.
Solo testing has a ceiling. Auth issues, data freshness problems, multi-user sync — these don't show up when it's just you clicking through your own app. They show up the moment a real person joins from a different device, in a different context than the one you built in.​
Open Questions
A few things worth exploring if this goes further — task filtering by person or category, custom expense splits for more complex events, and a native mobile experience. The expenses feature in particular has room to grow: right now it handles equal splits well, but real group dynamics are messier than that.
The more interesting question is whether the core holds up with a group that didn't build it. That's the test that matters.
Event Board App is deployed and in active testing. Google OAuth is currently in developer mode — reach out if you'd like access. [Link to GitHub Repo]