Personal event planning, without the bloat — for your dinner party, family trip, wedding, birthday. Multi-user from day one so the people planning it together actually plan it together.
a presentation of the requirements and tech plan, distilled from a multi-round discussion with the codex CLI.
Personal events are not what Eventbrite and Partiful are built for. You don't need ticketing. You don't need 12 RSVP form fields. You need who's coming, what's next, and how much it'll cost — and you need your partner / family / best friend to be in there with you.
Build a tight five-feature MVP, refuse most of the obvious extensions, and stay mobile-first. Make it real multi-user from the start — Alex marking 'venue booked' and Gerda seeing it within seconds is the whole point.
Real shared state, not screenshots. Six pillars that earn the word.
Passwordless magic-link email. Stable user ID across events and devices. No passwords, no OAuth. Account recovery = email recovery.
PostgreSQL is the single source of truth. The mobile Room database is a fast read cache; every write goes through the API with optimistic concurrency.
WebSockets, not polling. Per-event rooms; on any write, every other connected client gets a small push within 1-2 seconds and refreshes the affected view.
FCM data-only pushes go out when a member edits — even to phones that don't currently have the app open. Wakes the WS reconnect or surfaces a system notification.
Inviter clicks 'invite Alex'. Alex gets one email, one click, lands in the app already a member. Codex called this 'the thing you cannot fake' in V1.
Last-write-wins with version stamps. If Gerda edits while Alex is editing, the loser sees a 'someone updated this — refresh?' instead of a silent overwrite.
The smallest version where eventa is genuinely useful. If only these five exist, the app is already worth opening on event day.
title · dates · location · size · rough budget
why · Without an anchor, the rest of the app is a pile of tasks with no shared definition of success.
guests · households · dietary · lodging
why · Most planning decisions depend on headcount — and headcount is only useful when it includes real constraints.
android Import from device Contacts. Tap-to-call / SMS / email.
tasks · category · owner · due date
why · The app must help users know what to do next, not just store event data. Includes packing/supply lists.
overdue · this week · this month · later
why · Event stress comes from late decisions, not from lack of task storage. Reminders are the app's operating system.
android Local reminders for personal due-dates. Optional one-tap export to device Calendar.
estimated vs actual · paid-by · per category
why · Money is one of the fastest ways casual plans become stressful, and even rough visibility is valuable.
android Snap a receipt with the camera, attach to the line item.
Round 4 made these obvious — going native unlocks integrations a web app would have to build (or fake) from scratch.
personal due-dates fire even without server push
import a guest with one tap; no typing names + phones
call · SMS · email · navigate — straight from the row
receipts and contracts uploaded to the shared event
deadlines and run-of-show land in the device calendar
the active event is always viewable; writes need network
These don't ship on day one. They ship as the MVP gets used and the gaps become obvious.
one outreach covers a couple, family, or shared lodging group
why · Personal events are rarely individual-ticket affairs; household grouping avoids messy duplicate communication.
who paid for what · who owes whom
why · Essential for trips, group dinners, and family events. Track across event members + free-text labels; settlement is acknowledged manually, no money movement.
meals · drinks · portions · grocery quantities
why · Food is often the center of personal events; this prevents both overbuying and excluding guests.
save-the-date · invite · reminder · address request
why · Manual entries plus quick send-SMS / send-email buttons. Android permissions block automatic capture.
event-day schedule with times, owners, locations
why · Even casual events benefit from knowing when food arrives, people show up, speeches happen.
final costs · vendor feedback · what to repeat
why · Each event teaches the next one.
addresses · phone · booking refs · cancellation terms
why · Personal events depend on this fast.
every task / cost / run-of-show item has a clear owner
why · Owner can be a real event member (they see it) or a free-text label like "the caterer".
The expensive layers a multi-user event-planning app cannot ship without. None of these are 'after MVP'.
Backend slots into the existing tiny1 deploy stack (nginx + systemd + Let's Encrypt). Mobile reuses the same Compose/Material 3 setup as the other heapzilla android apps.
Functional + technical specs are at heapzilla-ai/eventa/REQUIREMENTS.md and TECHNICAL.md. Codex transcripts that produced this are checked in alongside, for traceability.
phase 1 of 9 starts with · deploy/projects/eventa-api.json
until then, read the spec · requirements.md · technical.md · plan.md