We pointed LiveGraph at an empty domain. It shipped a product.

October 2, 2026

modelright.dev is a live registry of AI model specs and pricing — ten providers' worth of context windows, token prices, and availability, queryable and comparable. Nobody wrote it. A LiveGraph bootstrap run created the repository, provisioned Cloudflare and Railway, delegated the nameservers, deployed the skeleton, and installed an improvement loop that then built the product through ten queued work items, each one a reviewed, CI-gated, human-approved pull request.

This post is the honest version of that story — including the parts that broke, because the parts that broke are where the product actually lives.

One run, then a loop

The App Bootstrap template is a run-once graph: Scaffold → Provisioner → approval gate → Deploy Verify. Scaffold creates the GitHub repo and pushes a Next.js+Postgres skeleton in a single commit — the agents have no filesystem, everything goes through GitHub's API. Provisioner creates the Cloudflare zone, captures the assigned nameservers, delegates them at the registrar's API, stands up the Railway project with app and Postgres services, writes the DNS records, and mints every secret the skeleton declares. A human gate sits before the verify hop — the last checkpoint before the run declares anything live.

Then the part that matters: the bootstrap installs a self-improvement loop on the new repo. Every ten minutes a tick reads QUEUE.md, the engineer picks the top item onto a branch, CI runs, a reviewer reads the actual diff, and a publisher sits behind a human approval gate before anything merges. The product plan was a paragraph. The queue items — the landing page, the compare page, the availability tracking — were written, implemented, reviewed, and merged by the loop.

What broke, and what that bought

Three honest failures, each now a feature:

• The queue file got wiped — four times. QUEUE.md is shared state the engineer edits while the base branch moves. A reparent step was once writing it from memory and once merged a stale snapshot clean. The fix wasn't a bigger warning comment: it's a deterministic diff-verification tool (verify_queue_diff) that the engineer, reviewer, planner, and both publishers must call — ok:false is treated as absolute, and a publish-time check now enforces “a QUEUE.md diff is exactly one line.”
• Deployed ≠ working. The first deploy passed its health check while the page rendered “No models available” — the schema migrations had never run and one required secret was never provisioned. The bootstrap template now ships a skeleton that self-migrates at boot, treats .env.example as the provisioning manifest for generated secrets, and the verify step probes a DB-backed route instead of trusting /health alone.
• A DNS detail stalled TLS for a day. Railway's custom-domain flow returns verification records — a _railway-verify TXT — that the provisioner was skipping, leaving the domain in VALIDATING_OWNERSHIP. The prompt now applies every record Railway asks for, and subdomain setups reuse the parent zone instead of trying to create one.

Why a graph, not a script

Every hop of that run was visible, interruptible, and steerable while it happened — and the failures above surfaced as markers and parked approvals, not silent state. When the queue file corrupted, we didn't restart a pipeline; we watched the conflict-fix round run, approved the reparented PR, and hardened the machinery the same week. That loop is still running: modelright.dev continues to improve itself on a 10-minute tick, and every merge still parks at a human gate. (The live canvas demo shows the same steer-a-running-graph mechanics on a scripted model — no keys, no spend.)

The same template is what a new user gets: pick App Bootstrap, fill six fields, press “Start the build,” and watch a domain become a self-improving product — with a build-status page tracking every marker the run emits.