Mark Cipolla

The mental load of running a household mostly arrives as email. School notices, sports rosters, party invitations, appointment reminders: all of it lands in one person's inbox, and that person becomes the household's scheduler by default.

household.email gives every family its own mailbox, like yourfamily@household.email. Hand that address to the school, the swim club and the dentist, or forward mail to it from wherever it already arrives. Everything sent there becomes a shared triage queue that the whole household can see, rather than a pile in one person's personal inbox.

Incoming mail is parsed, and an AI pass pulls out the events, dates and actions hiding in it. Nothing is filed without a human confirming it first: the extracted event is a suggestion you review, edit or discard. Once confirmed, it lands on the shared calendar, or becomes a todo, a chore, or a line on a shopping list.

Around the inbox sits the rest of the household: a shared calendar with recurring events and birthdays, todos with assignment and due dates, rotating chores, shopping lists, and meal planning with a recipe box you can fill by forwarding a recipe to the same address. Google Calendar and Google Tasks sync both ways, and there's a read-only iCal feed for anyone who would rather stay in their own calendar app.

It's a Rails 8 monorepo. The web app is the single source of truth for the UI: Hotwire with Turbo morphing and Stimulus, Sprockets and importmaps, so there's no Node build step. PostgreSQL does all the heavy lifting, including background jobs (Solid Queue), caching (Solid Cache) and websockets (Solid Cable), which means no Redis to run. iOS and Android ship as Hotwire Native shells around the same views, so there's no second mobile UI codebase to keep in step. A reMarkable 2 client written in Rust is the one exception: the tablet has no browser, so it reads the JSON API and draws the week's meals on e-ink itself.

The AI pass runs on open-weight models we host ourselves on Modal, rather than sending a household's mail to a third-party model provider. The provider is a single environment variable, so it can move again without touching the extraction code.

The whole thing deploys as a single Docker image run in several roles, web and workers, onto a VPS with Kamal. GitHub Actions runs the test suite across five shards alongside Brakeman, RuboCop and Packwerk boundary checks, then builds and pushes the image; staging deploys itself on green, and production is a one-click workflow.

household.email is in early access, building out a waitlist ahead of a wider launch.