AI Front Desk

Many small businesses have websites that answer only static questions. AI Front Desk explores a product architecture where a business can onboard from its website URL, generate a structured business profile from crawled content, review or publish that profile, and expose an embeddable AI widget to visitors. The hard part is not just chat with a website; it is the product surface around tenant setup, ingestion jobs, profile review, widget configuration, runtime limits, billing hooks, and a demo experience that makes the system understandable.

• Split product architecture across a Next.js platform repository and a Flask API repository.
• Standalone widget bundle mounts in Shadow DOM and exposes public init/destroy lifecycle functions.
• Frontend route handlers proxy widget, onboarding, preview, billing, dashboard, and website-ingestion flows to backend endpoints.
• Backend ingestion routes support tenant creation, crawl-job enqueueing, resync, draft review, and publish flow.
• Widget runtime validates preview/live access, allowed origins, published profile availability, usage limits, and per-minute rate limits.
• Stripe routes support plan listing, checkout sessions, portal sessions, webhooks, paid onboarding, and install-script generation.
• Postgres migrations cover tenants, crawl jobs, tenant site identity, assistant profile versions, launch support, preview sessions, and widget keys.
• Production checks cover linting, tests, e2e tests, migration dry runs, contract conformance, roadmap sync, and harness health.

AI Front Desk is framed as an AI product system, not a chatbot demo. Website content moves through ingestion, profile generation, review, and publication before it becomes runtime context. That intermediate profile gives the product a safer control point: trusted facts, official links, tone, quick actions, quotas, allowed origins, and widget behavior are represented as tenant configuration rather than left to free-form visitor chat.

The product intentionally avoids deep transactional workflows inside the assistant. The spec keeps bookings, payments, and broad CRM behavior outside the current runtime, routing visitors toward official systems instead. That keeps the architecture focused on onboarding, profile control, widget delivery, and bounded runtime behavior before expanding into higher-risk integrations.

AI Front Desk demonstrates full-stack product engineering around an AI-native SaaS concept. It shows I can think beyond a prompt box: onboarding, crawling, tenant state, embeddable distribution, billing, rate limits, usage controls, frontend demos, backend workers, and governance checks.

• Add an architecture diagram for onboarding, crawl jobs, profile review, publication, and widget runtime.
• Add admin dashboard screenshots for the tenant lifecycle.
• Add clearer data model documentation.
• Add evaluation fixtures for assistant answer quality.
• Add observability around crawl failures and widget usage.
• Add richer tenant configuration controls.

• The platform README documents the launch surface, /widget.js bundle, embed guide, frontend ownership boundary, and production checks.
• app/SPECS.md defines the multi-tenant assistant model, server-owned Client Profile, allowed origins, quotas, and non-goals.
• packages/embed-widget/src/index.ts and api.ts implement script-tag configuration, Shadow DOM mounting, widget config loading, and chat submission.
• The API README documents tenant onboarding, website ingestion and resync jobs, profile review/publish flow, widget runtime, usage logging, limits, billing, and production checks.
• routes/website_ingestion/routes.py, routes/widget/runtime.py, routes/billing/routes.py, and migrations/sql/* provide the concrete backend evidence for the product boundary.