Domus

domusai.tech website

Inspiration

We've all felt the loneliness of moving to a new city or being new to a community especially around meaningful moments like Shabbat, Eid, holidays, or Sunday dinners. Those meals happen in people's homes every week, yet there's no way to find them if you weren't already invited. DOMUS started from a simple question: what if the table was open to anyone who wanted to belong?

What it does

DOMUS is a home-hosted dinner discovery platform. Hosts post faith and cultural gatherings (dinners, holiday meals, community celebrations) with details on tradition level, dietary accommodations, and available seats. Guests browse events, filter by religion and location, and send a short request to join. Hosts review profiles and approve guests, then everyone shows up ready to share a meal. The app also includes guest–host messaging, a personal calendar of upcoming commitments, and public profiles with a follow system so you can stay connected with hosts you love.

How we built it

Frontend: React 19 + TanStack Start / Router / Query, Vite, TypeScript
Styling: Tailwind CSS v4, Radix UI primitives, shadcn/ui component patterns
Backend: Supabase (Postgres, Auth with Google OAuth + PKCE, Row Level Security, Storage for avatars)
AI features: OpenRouter (server-side) for browse city suggestions and an in-app assistant ("Borat") that answers questions about events and hosting
Maps / geo: Google Maps JS API + Nominatim geocoding for distance-sorted browse
Hosting: Vercel with a Cloudflare Workers-compatible SSR bundle

We built the entire product (schema, auth, routing, browse logic, messaging, calendar, and AI integrations) during the hackathon weekend.

Challenges we ran into

OAuth redirect hell. Google's PKCE flow sends users back to the Supabase "Site URL" rather than the page they started sign-in from, which can land them on localhost in production. We built an automatic recovery layer that bookmarks the starting origin before the Google redirect and bounces the ?code= callback back to the correct host when it arrives on the wrong one. Religion-aware filtering. "Jewish event" sounds simple until you're matching Judaism against an event tagged Halal and your keyword fallback fires incorrectly. We separated canonical religion matching from keyword inference so explicit tradition labels always take precedence. Photo upload policies. Supabase Storage RLS policies using storage.foldername() were silently denied for certain auth states. We rewrote them with split_part(name, '/', 1) and added an idempotent server-side RPC to ensure the bucket exists before every upload attempt.

Accomplishments that we're proud of

A fully working end-to-end flow: sign up → profile → browse → request → approve → message → calendar, all in 36 hours
Religion-aware event matching that respects strict dietary traditions without false positives
AI-assisted city suggestions that make the browse filter feel alive even when the database is sparse
A clean, warm UI that feels like the product belongs on a dinner table, not a dashboard

What we learned

Building trust into a two-sided marketplace is harder than building features. Every design decision, profile fields, request messages, host approval, had to answer "would a host feel comfortable saying yes?" before it shipped. We also learned how much Supabase's RLS and PKCE auth reward careful planning upfront; fighting either in the middle of a hackathon is expensive.

What's next for Domus

Ratings and reviews after attended events so reputation builds on both sides
Recurring events so a host who runs every-Friday Shabbat doesn't retype it weekly
Waitlists and seat limits with automatic notifications when a spot opens
Mobile app the browse-and-request flow is native-ready
City expansion beyond the initial launch cities, driven by host signups