Your first launch checklist

What do I need before starting?

The template is free to claim after signing in to ioy.ai. Model inference, domains, email, payment processing and Cloudflare usage have independent costs. The public Skill installer needs Node.js 22.20+ and Git; building this template requires Node.js 24+.

Choose a standard workspace or one-page tool. Define the eight requirements in the product guide. Keep credentials in local environment variables or Secrets, never in the brief or chat.

How do I create my project?

Claim your one-hour, read-only clone credential, clone the clean release, and run from that directory:

npm ci
npm run ioy -- create --config examples/requirements.json --out ../my-product

For the one-page version, use examples/one-page.json. Edit a copy with your own product facts first. The output must be empty and outside the template. A successful command produces an independent project, README, requirements, launch configuration and versioned API Skill. It does not prove that external services are ready.

What should work locally?

Inside the generated project, install dependencies, initialize the local database and run checks:

npm ci
npm run db:local
npm run check
npm run test:ui:isolated
npm run dev

Review the actual input/output, task history, file isolation and account states. Default local email and AI are simulations. Fix local failures before creating remote resources. The public demo is read-only and uses fixed samples; it cannot log you in, generate, upload, charge or modify admin records.

How does the CLI guide deployment?

Set your account, resource names and preview origin in Wrangler, then set cloudflare.zoneId in launch-config.json. Start with APP_ENV=preview and disabled AI/billing until the corresponding services are configured.

npm run ioy -- doctor --config launch-config.json
npm run ioy -- launch --config launch-config.json
npm run ioy -- status --config launch-config.json
npm run ioy -- resume --config launch-config.json

The coordinator checks tools and selected configuration, runs local acceptance, reuses or creates independent D1/R2 resources, deploys preview, and binds/verifies the owned domain. It then guides Google, email/model, payment and production acceptance. Resource and domain permissions are checked with real requests; having a Wrangler login does not grant every scope.

Each stage is pending, running, complete, blocked or unknown. A blocked stage names the missing configuration or verification. An unknown write must be reconciled before retrying. Checkpoints are local under ignored output/launch, with no CLI telemetry or credential values. A stale lock records its PID: check whether the process is alive, remove only the stale lock, and retain the journal.

When are Google, email, models and payments ready?

After formal HTTPS is verified, configure the Web OAuth client through Google Auth Platform. Use the Skill's Google branch to verify origins/redirects, OAuth/One Tap, GA4 received events and Search Console ownership. The CLI can run the existing GA4/Search Console helpers when the required account choices and scopes exist. Missing account authorization requires the account holder; it is not inferred from a Google browser session.

Verify delivered verification/reset emails, actual model output and cost rates, then the selected payment provider's signed sandbox outcomes and live catalog. Three adapters do not mean three approved merchant accounts. Use the provider Skill/CLI branch for product setup; the coordinator never invents product IDs or marks configuration as a transaction.

Record acceptance in the launch configuration only after inspecting evidence. Each record includes status: verified, the matching formal origin, templateVersion, checkedAt and a relative local evidence path. The coordinator requires fresh records (24 hours). Keys are google, services, sandbox, paymentLive and production. Do not include tokens or raw provider responses.

How do I release and recover?

Set productionConfig to a separate production Wrangler configuration and verify its independent resources and formal origin. Domain ownership conflicts require a deliberate migration before publishing. The coordinator backs up the selected production database, applies compatible migrations, runs guarded deployment and verifies public URLs. It still requires real production-flow evidence before reporting completion.

After production deployment has started, resume does not replay preview deployment. Keep the previous Worker version and template release ID for rollback; rolling back code does not roll back database changes. See the deployment guide and troubleshooting.