Production systems for regulated, high-stakes software.

The decision that hurt was killing a shipped page. Big7 launched with three buyer lanes; the 2026-07 restructure collapsed that to two buyer paths — Commercial & Industrial and Residential — with Home Repair folded into the residential page as an in-page section. Separate audience pages rank and convert better than one homepage trying to serve everyone, but home repair didn't have the volume to justify its own destination page. The old URL 301s to the new section and legacy query-string intent links are caught by an inline shim, so no inbound link ever broke.

That restructure moved the money path. The homepage now carries no form at all — it's a lean chooser routing to two lane pages, each owning a tailored intake form. Two forms means two copies of submit, prefill, and analytics JS, so that code was extracted into one shared big7.js loaded on every page: inline copies drift, and drift in money code is how intakes silently die. Leads mirror to an n8n webhook fire-and-forget while Formspree remains the path of record, because a verified money path never gets swapped silently for a new one.

The accessibility tradeoff was visual: the primary CTA orange failed WCAG AA at 3.48:1 contrast on white text. Rather than invent a new palette token, the base color moved one step down the existing ramp to roughly 5.05:1 and hover became a brightness filter — the button reads slightly darker than the original brand orange, and that is the accepted price.

What keeps it honest: 21 structural contract-test scripts parse the shipped HTML and lock the Formspree endpoint (a wrong action attribute still returns 200 in the browser while intakes land nowhere), the required fields, the spam honeypot, the tel: link agreeing digit-for-digit with the JSON-LD phone number, and real 404s — a missing path returns an actual 404 page instead of an SPA-style silent rewrite to the homepage, which would otherwise poison SEO and analytics.

Sold-at-handoff changes the engineering contract. Ownership transferred with the site, so it was built to run without its builder: static hosting with nothing to patch, no framework churn, no CMS to maintain, and no dependency that expires — boring outcomes chosen on purpose for a client who owns the result.

The discipline that proves it: the live V1 is frozen to me. Once a client owns their site, edits go through them — the production system's word is theirs now. A client-approved V2 rebuild exists as a separate track, gated on their walkthrough and sign-off before any cutover touches the live property.

The widget's public API is one script tag plus a per-tenant JSON config — no SDK, no secret on the host page. That promise has a price: with no API token to check, tenant auth has to be origin-based, and the allowlist has to live server-side.

The decision that hurt: the default tenant. Unknown site IDs originally fell back to a default config that shipped without an origin allowlist, which the config layer treated as allow-anything. Any site on the internet could paste the script tag with a made-up site ID and stream Claude tokens off the production API key — and rotating site IDs multiplied the effective rate-limit quota. Closed before charging money by locking the default tenant to the SiteGuide domain itself. The hard-404 alternative was rejected to keep demo ergonomics (the store previews would-be tenant IDs), and per-embedder API tokens were rejected because a secret in every customer's HTML breaks the one-tag promise and turns key rotation into a coordination problem.

CORS stays deliberately wide open while the chat endpoint enforces the per-tenant origin check, because CORS is a browser convention, not a server-side security boundary — curl ignores it entirely. The rate limiter is an in-memory sliding window, which only works because Railway runs a single instance; horizontal scaling means moving that state somewhere shared, a cost deliberately not paid yet. Prompt caching on the system prompt is mandatory in the Claude client — it is the difference between a demo-priced and a production-priced token bill.

Measured result: all 19 templates are live and sellable behind a Stripe checkout → idempotent webhook → entitlement → protected ZIP → confirmation-email flow, verified with a real purchase in production. A parametrized drift test fails the suite if any sellable tenant ships without an origin allowlist, and 660 test functions across 31 files keep it that way.

The first real production question broke retrieval, and the failure was structural, not a fluke. Search used Postgres full-text search, which ANDs every stemmed content word together — a chunk had to match every word of the question inside the same ~800-character window. "What is the role of an enabling team in a microservice architecture?" returned "I couldn't find relevant information" against a manual with a full page on enabling teams. Verified directly against the live database: zero rows for the strict AND match, while three chunks discussed the topic at length — none happened to also say "role" and "architecture" in the same chunk.

The designed answer already existed in the codebase: vector and hybrid search behind feature flags, with the pgvector column and index already migrated. But no embeddings had been backfilled and no embedding-provider key was set — turning the flags on meant a real migration-and-backfill pass, not a flag flip. The chosen fix was deliberately cheap: when the strict AND returns zero rows, retry the same lexemes OR'd together, ranked so chunks matching more terms still win. Zero new infrastructure, zero new API cost, one extra query only on the already-rare found-nothing path. Measured before the code was written: the OR-relaxed query returned six ranked results for the exact failing question, including both chunks that actually answer it.

Deployment had its own hurt: the first live deploy 500'd in a way that looked exactly like a CORS block, because an uncaught exception bypasses the CORS middleware's header-attaching step. The real traceback, pulled from Railway's deployment logs, was psycopg2 failing with "Network is unreachable" — Supabase's direct Postgres host resolves to IPv6 and Railway containers have no outbound IPv6 route. Fixed by switching to Supabase's IPv4-only connection pooler, safe here because the backend opens one connection per call and relies on no session-level state.

The lesson that stuck: get the real traceback before declaring a fix, and never trust a green local suite when CI's entry point differs — 450+ backend test functions now lock the retry behavior, the CORS fallback parsing, and the retry-backoff math.