An installer and verification toolkit for an agency running the same AI receptionist install, website, chat and phone agent, for many small businesses. One command sets a client up. A second runs thirteen automated pass/fail checks against the live install. A third rechecks it later for anything that's drifted.
There's no client on this one either, but there is a live install to check. The site it's tested against is a fake plumbing company this tool provisioned and verifies against itself, linked below. It's here because building the checks turned up more real bugs than writing the product did.
The live install is a real deployment, not a mockup. A fake plumbing company with a working site, a chat assistant, and a voice agent you can talk to in the browser. A banner on every page says as much and links to its latest verify report.
See the live demoA small business's AI receptionist isn't one thing, it's a website, a chat assistant, a phone line, a database, and email alerts to the owner, all set up together. Do that by hand for one client and it's manageable. Do it for twenty and the failures stop being obvious. A phone webhook still points at a URL from three months ago. A key leaks into the code sent to visitors' browsers. One business's dashboard quietly shows another business's leads.
None of those crash anything. The owner usually finds out from an angry customer, not from a dashboard. That's the gap this closes: prove the install is safe before a person has to discover it isn't.
Every gate runs against a live, deployed install, not a mock of one. A trimmed line from an actual run: rate limits are proven by sending eleven messages under an isolated test key until the real limit returns a 429. Cross-tenant isolation is proven by having a real account for tenant A try to read tenant B's rows and fail. SEO is proven by fetching the live sitemap and robots.txt and parsing the structured data that's actually on the page, not by checking that the code that generates them compiles.
An install with no Twilio account yet doesn't fail the phone number check, it's marked skipped. Treating "not set up" the same as "broken" would train whoever reads the report to stop trusting FAIL, which defeats the report's whole purpose.
Not the source, the compiled site that ships to a visitor's browser. It's the only way to catch a key that leaked in through a dependency or a build step nobody was watching, rather than one you'd only find by reading the code you wrote yourself.
Pages load, the consent gate, the webhook signature, secrets, rate limits, SEO, and more work against any AI receptionist install that follows the same handful of conventions, not only ones this tool provisioned. Point frontdesk check --target at a URL and whatever credentials you have, and it skips only what it can't test.
Every claim below was run against the real deployed site and its real vendor accounts, not written and trusted: a real Gemini call answering FAQ questions and correctly declining to guess a price, real email delivery confirmed in Resend for a new lead and a completed call, an ElevenLabs voice agent's settings read back from the live agent rather than from its own config file, the phone webhook's signature check tested valid, unsigned, and tampered, and CI plus the Vercel and worker deploys both green on GitHub Actions.
What hasn't been run yet, because it needs a Twilio account I don't have: an actual inbound phone call, start to finish. Everything that can be proven without one, the webhook signature, the handoff to the agent, the database writes, already has been.
The README claimed thirteen gates for a while before the code actually ran thirteen. Gate 13 existed, was written, had tests, and simply wasn't wired into the command that runs the other twelve, so verify silently ran twelve and called it done. Nothing in the code was wrong, it was just never called. I only caught it by running verify live and noticing a row missing from the printed table, which is exactly the kind of thing that doesn't show up from reading the code.
Running the local no-account demo end to end, not just typechecking it, found three more. Node's execFileSync on npm or npx needs shell: true on Windows, or it fails immediately, either silently or with the wrong error depending on how you got it wrong. A required environment variable was being blanked to an empty string for the demo, and Next.js's own startup validation, not the CLI's, rejected it. And disabling the voice and phone vendors for the demo by deleting those variables instead of setting them empty let Node's own env loader quietly refill them from a real .env.local file, which meant a local "demo mode" run could turn real voice calls back on without saying so.
Chat replies in local demo mode take fifteen to twenty seconds against a mock provider that has no network calls to wait on and should answer near-instantly. It isn't a cold-start effect, the second request is exactly as slow as the first. Not yet root-caused. My working guess is it's specific to the sandboxed environment I was developing in rather than a real bug, but I haven't confirmed that on a normal machine yet, so I'm saying so rather than guessing.
The kitchen system holds back anything it can't verify instead of guessing, because guessing wrong reaches someone's plate. This tool applies the same rule to my own work: SKIPPED instead of a false PASS, a secret scan on the actual shipped output instead of trusting the source, a rate limit proven by tripping it for real instead of trusting the config that's supposed to enforce it.
And it only earns that trust because it got run, not just written. The missing gate, the Windows shell bug, the env var that silently came back, none of those were visible from reading the code. They showed up the moment something actually executed it.
Twenty minutes. Tell me how it's set up now and where it's gone wrong before, and I'll tell you whether an automated check is worth building for it.
