QuoteReady
A revenue website and governed front office for service companies: a customer request becomes a structured job, AI prepares the packet — and no more — the owner prices it, and the same job moves from inbound request to booked appointment.
The demo runs the product's actual domain layer — state machine, quote and booking commands, AI packet pipeline, tokens, outbox, expiry sweep — vendored at a pinned commit, against a fresh fabricated business per run. You play the customer and the owner; no account, no email, no signup.
The problem
Small service companies lose jobs between "a customer asked" and "the work is on the calendar." The request arrives by phone, text, or a contact form; the details live in someone's head; the quote goes out late or not at all; the customer accepts and then nobody pins down a time. The website describes the business instead of operating it, and the owner is the only workflow engine the company has.
What the system does
QuoteReady gives the business a generated, published website whose request form creates real operational state: a Job with sixteen canonical states and one transition writer. AI reads the request and prepares a job packet — items, gaps, risk flags — inside a schema that structurally cannot contain a price. The owner decides the price and sends the quote on a one-time link; the customer accepts on that link; the owner offers one appointment window at a time; the customer confirms or asks for another. Messaging runs through a deterministic policy gate, every action lands in an append-only audit trail, and a background worker sweeps stale offers without ever touching a confirmed booking.
Authority is the architecture
The AI is one bounded worker inside a governed system — not the hero. Its packet schema has no price field, so a priced packet is structurally impossible; it can move a job to exactly two states; it cannot send a message. The decisions that commit the business stay with the people who own them.
CUSTOMER REQUEST ──▶ JOB (16 states, one transition writer)
│
AI PREPARES ─────┤ the packet: items, gaps, risk flags
│ (schema has no price field)
OWNER DECIDES ─────┤ price · whether to quote · the time window
│
CUSTOMER DECIDES ────┤ accept / decline · confirm / reschedule
│ (one-time links, hashes only at rest)
SYSTEM ENFORCES ────┘ state · tokens · expiry · idempotency · tenancyWhat exists today
Every claim here is graded from a source-level inspection of the product repository. The categories do not blur: implemented against a fake provider is not a production integration, a deployed engine is not a launched product, and this page becomes more credible as more of the implementation is exposed, not more promotional.
Implemented & gate-verified
The full front-office engine: website generation and publish/rollback lifecycle, public intake with photos and persist-nothing bot defenses, AI job packets under a strict no-price schema with a complete failure taxonomy, the owner command center, quotes with revisions and one-time hashed customer tokens, one-window booking with reschedule/re-offer, the command-layer past-window defense and CAS expiry sweep, transactional messaging through a deterministic policy gate with quiet hours and opt-out, missing-information round-trips, AI reply drafts (advisory only), the transactional outbox and worker, idempotency, four-layer tenancy, and append-only audit. Nine milestone gates run against the real production build — eight over HTTP, four also booting the real worker process — plus ~1,800 unit and integration tests.
Demonstrated
Everything the working demo shows: the generated website, a controlled request becoming a real Job, a live-model packet accepted by the product's own strict schema (with any invalid live output preserved as a rejected attempt before the deterministic fallback runs), the owner's quote on a one-time link, acceptance with a double-click replay proof, the reschedule → re-offer loop with the consumed link provably dead, the booking climax, and the two-layer expiry defense — all through vendored product commands at a pinned commit.
Production-deployed
The engine itself runs deployed — web and worker processes, live database with row-level security under a dedicated role, live Anthropic packet generation, health and schema-compatibility gates, and a manually-dispatched production browser smoke. Deployed is not launched: no customer uses it, and photo storage, messaging and domains below are not production-grade yet.
In development
The distance to a first design partner: the admin console UI (backend commands exist; the console does not), durable object storage for photos (local disk today), live email and SMS providers (Twilio and Postmark adapters are implemented and tested, but production runs fake providers by explicit override), custom domains (a placeholder column, no flow), and the follow-up pause scope (defined, not yet enforced — follow-ups stop via the messaging pause today).
Planned
Billing (no payment code exists yet; design partners would pay by manual invoice first), the review-request loop, the automated staleness scheduler, additional verticals beyond junk removal, and self-serve signup as a lit path (the flow exists but is deliberately dark until live email delivery is proven).
The journey the demo proves
REQUEST → AI PACKET → OWNER QUOTE → ACCEPTED → ONE WINDOW → RESCHEDULE → RE-OFFER → CONFIRMED → BOOKED
The business climax
A customer request became a booked job — through real commands, from both sides of the counter. The reschedule loop is the product's own texture: one window per offer, the customer's “this time doesn't work” handing the job back, the re-offer retiring the old one-time link.
The governance climax
A stale confirmation is refused twice, at two layers: the command layer fails it closed before any sweep runs, then the worker's real sweep formalizes the expiry and returns the job to the owner — while a confirmed booking can never be expired, because a single compare-and-swap update lets exactly one side win. Governed, not merely automated.
Current capabilities
- A published, SEO-complete business website generated deterministically from the business profile — the request form is the front door to the workflow, not a contact box
- Public intake that creates a Job, customer record, and claimed photos in one transaction — with honeypot, minimum-age, and magic-byte photo sniffing that persist nothing when a bot trips them
- AI job packets under a strict schema with no price field: extraction with per-field confidence, missing-information detection, and risk flags — the AI can mark a job quote-ready, and nothing else
- Owner-only pricing and quote commands ("no AI-authored number can reach a customer"), quote revisions that supersede the prior quote and kill its link, and one-time customer action tokens stored only as hashes
- One booking window per offer: reschedule hands the job back, re-offering retires the old link, a past window fails closed at the command layer before any sweep runs, and the expiry sweep's CAS can never corrupt a confirmed booking
- A transactional outbox with idempotent consumers, a central idempotency store layered with compare-and-swap state transitions, four-layer tenant isolation, and an append-only audit trail enforced by database triggers
Limitations, stated plainly
- Not launched: no customer uses the deployed engine, and the product's own docs gate a design-partner launch on a full golden test that today's build cannot yet pass.
- Messaging runs on fake providers in production by explicit override; the Twilio/Postmark adapters are implemented and tested but not production-proven, and no SMS/A2P registration exists yet.
- One vertical exists — junk removal. The website template, intake fields, and the fake AI provider's heuristics are all junk-removal-native; no other vertical is claimed.
- Photo storage is local disk in the deployed environment (files do not survive a redeploy); durable object storage is the named next step.
- The product has no clock seam: the demo's expiry scenario advances time by aging the offered window — the same governed fixture advance the product's own tests use — and says so on the surface. Every staleness decision is product code.
- The demo executes the product's real dispatcher, consumers and sweep functions deterministically; the deployed product uses the persistent worker + pg-boss and therefore additionally has background retry behavior that the demo does not reproduce.
Technical shape
A TypeScript monorepo: a Next.js web process and a long-lived Node worker over one Postgres schema — sixteen job states behind a single transition writer with CAS and a central idempotency store; a transactional outbox whose consumers are pure functions of their event; one AI seam where output crosses as untrusted data and a strict zod parse is the sole acceptance authority; one-time customer tokens hashed at rest with uniform-null death; append-only audit enforced by API guard, database trigger, and row-level security. The public demo vendors that domain layer at a pinned, hash-manifested commit with a CI tamper check; each run is a fresh fabricated business in a dedicated database, isolated by the product's own tenancy fences under this site's run-token model, spending from the site-wide daily AI budget, purged completely after 24 hours.
This product is in active development — a deployed, gate-proven engine that has not yet earned the word “launched.” The demonstration is real: it executes the product's actual commands. The service is not yet shipped, and this page does not pretend otherwise.