Frontdesk

A single-script-tag AI chat widget for local business websites - answers common patient/customer questions (hours, services, booking, location), captures leads it can't answer, hands off anything urgent to a phone call. Sold direct as a monthly subscription - no marketplace cut.

First target: West London Dental Centres (dentistw4.co.uk), Chiswick.

Future idea: a premium tier that takes payment in-chat (not built yet)

Instead of just capturing a lead for the business to follow up on, Sia closes the transaction herself - customer books and pays right in the widget. Noted here so it doesn't get lost, deliberately not scoped for now - it's a materially bigger build than anything else in this project:

• Needs real availability/calendar data, not just FAQ config - can't sell a slot without knowing what's actually free.
• Needs Stripe Connect, not a simple Payment Link - money has to land in each business's own account, so every client onboards their own connected Stripe account (KYC, payouts) and the backend routes to the right one per transaction.
• Raises the error budget a lot - a bug here means misplaced money or a double-booked slot, not just a missed FAQ answer, so it needs more careful building/testing than anything shipped so far.

Right sequencing: after client #1 is real and paying, not before. Also a legitimate premium-tier price justification once it exists - "closes sales while you sleep" is worth noticeably more than £45/mo.

Future idea: give Claude read-only Stripe access (not built yet)

Once there are real paying clients, it'd be useful for Claude to answer things like "how many are actually paying right now," "did anyone's payment fail this month," "what's MRR" - direct reporting instead of digging through the Stripe dashboard by hand.

How, when we get there: a Stripe Restricted API key, scoped to read-only on Payment Links / Subscriptions / Charges specifically. No refund, payout, transfer, or account-settings permissions on that key - ever. Stored the same way as the other secrets (env var, never pasted loosely in chat).

Hard line, not just a preference: anything write/mutating - issuing a refund, cancelling a client's subscription, changing payout details, creating new pricing products - stays prepare-but-don't-execute even with that key in hand. Claude drafts the action, a person clicks confirm. This isn't extra caution for its own sake - it's the same boundary Claude already operates under around moving money, and it matches Stripe's own least-privilege guidance for exactly this kind of access.

Timing: not urgent - nothing to report on with zero paying clients. Worth doing once there's real subscription activity to actually watch.

Future idea: further AI cost-reduction levers (not built yet)

api/chat.js's system prompt is cache_control-marked and confirmed working (see "What's built" below), but testing found Haiku's minimum cacheable prompt size sits above what a typical business's config actually reaches even with the new 1000-char training text - so this is correctly wired for the businesses with the largest configs, not a general win yet. Real levers still on the table, logged here for later once there's volume to justify the complexity:

• A business with an unusually large config is exactly who caching already helps today - worth knowing which real clients are on the bigger end of FAQ/training-text usage, since they're the ones actually seeing the discount right now without any further work.
• Model routing - a lot of questions are simple lookups ("what are your hours") that don't need a full Haiku call at all; a cheap keyword pre-check that only calls the AI for genuinely open-ended questions would cut volume further. Real complexity/accuracy trade-off - only worth it once token cost is actually a line item that matters.
• Per-business usage visibility - right now there's no per-client view of how many messages/tokens a business is generating. Useful both for cost tracking and for catching one client accidentally driving disproportionate usage (or abuse) before it shows up as a surprise bill.
• Batch processing (Anthropic offers ~50% off for non-real-time batched requests) - not applicable to live chat itself, but could apply to something like a nightly "summarize missed questions" digest if that ever gets built.
• Longer/tiered caching - if Anthropic offers longer cache TTLs than the default ephemeral window, worth revisiting once a business's traffic pattern is well understood (bursty during business hours vs. spread evenly changes what a longer cache window is actually worth).

This is the beginning of the README. Read the rest at the original. Read the full README ↗