Fondas

Hotel operations SaaS for independent hotel GMs (20–200 rooms).

Naming: the product is Fondas (as shown in the wordmark, emails, and legal pages). The visual design system was called Signal (v2, FONDA_DESIGN_IDENTITY.md) and is now Fonda × Sana (v4, FONDA_SANA_REDESIGN.md); "Fonda" in design-token comments refers to that system, not the product.

Go-to-market — strategy, positioning, the pilot playbook and the current sprint — lives in gtm/.

Core surfaces, live as of 19 Sep 2026:

• Home — leads with what needs you today; the tiles are user-customisable
• Ask — chat over the hotel's own data, with persistent conversations and a source chip per answer saying what it was built from
• Morning brief — a daily summary, with per-section provenance
• Arrivals & departures — two tabs, plus the arrival-time chaser queue
• Communications — two windows, In-house and Upcoming, with a queue framing (Needs you · Waiting · Done today) and a guest context pane at xl
• Guests — the list and the record: inferred tags, staff notes inference never touches, and a merged timeline of mail, chasers and prior stays
• ⌘K — pages, guests, and "Ask: …"

Not yet built: Billing (blocked on the legal entity) and Reputation (blocked on a review-source decision). See ROADMAP.md, which is the only roadmap.

Stack

• Next.js 16 (App Router). Note: Next.js 16 renamed Middleware to Proxy (proxy.ts at the project root) — see proxy.ts.
• Supabase for auth (email/password) and database
• shadcn/ui + Tailwind CSS v4 for components
• Geist + Geist Mono, on a white canvas with warm grey wells (#F6F3EE) grouping content, and colorless chrome. The design authority is FONDA_SANA_REDESIGN.md (v4 "Sana, actually") — read its §0.1 first, as it inverts the ground and replaces the icon rail that the rest of that document is written around. FONDA_DESIGN_IDENTITY.md (v2 "Signal") is background only. Never hard-code hex — reference the CSS variables in app/globals.css.

Getting started

cp .env.example .env.local   # fill in your Supabase + API keys
npm install
npm run dev

Then open http://localhost:3000.

You need a Supabase project. Copy the project URL and anon key into .env.local. Email/password auth is enabled by default in Supabase. For local development without email confirmation, disable "Confirm email" under Authentication → Providers → Email.

Project structure

app/
  (auth)/            Login & signup (route group, no URL segment)
    actions.ts       Server Actions: login / signup / logout
    login/           /login
    signup/          /signup
  dashboard/         Protected area (guarded by proxy.ts + layout check)
  layout.tsx         Root layout (Geist fonts, metadata)
  page.tsx           Marketing landing page
components/
  ui/                shadcn/ui primitives (button, input, label, card)
  auth/              Auth form
  brand/             Wordmark
lib/
  supabase/          client (browser), server (RSC/actions), proxy (session)
  features.ts        The four product surfaces
  utils.ts           cn() helper
types/               Shared domain types
proxy.ts             Session refresh + /dashboard guard (Next.js 16 "Proxy")

Database

The schema lives in supabase/migrations/0001_init.sql: hotels, users, briefings, emails, checkin_chasers, hotel_settings.

Apply it with the Supabase CLI (supabase db push) or by pasting the file into the Supabase SQL Editor.

Tenancy & RLS. Every row belongs to one hotel, and a user belongs to one hotel. Row-Level Security restricts all reads to the caller's hotel, resolved via the public.current_hotel_id() helper (a SECURITY DEFINER function — this is what lets the users policy reference its own table without recursion). Owner-only and self-only rules are layered on top for writes.

Provisioning is server-side. There's deliberately no client INSERT policy on hotels or users — a user could otherwise attach themselves to any hotel. Create the hotel + first user row from a trusted context using the service_role key (which bypasses RLS), e.g. during onboarding.

Auth flow

• Unauthenticated requests to /dashboard/* are redirected to /login by proxy.ts (with a redirectTo param), and again by the dashboard layout as defense-in-depth.
• Authenticated users visiting /login or /signup are sent to /dashboard.
• lib/supabase/server.ts and lib/supabase/proxy.ts keep the session cookies fresh on every request.