From vibe coding preview to production

Separate preview from production

A preview can use different data, credentials, or build behavior from the public release. Write down which environment is being tested and which backend the published application will use. Inspect the production configuration rather than assuming a successful preview proves the live app is ready.

For a content site, test direct requests to every important route. A static host must return the page's real HTML, not a JavaScript shell with the homepage title. For a data-driven app, test the published environment with controlled accounts and non-sensitive data before opening access more widely.

Run a release checklist

Run the project's typecheck, tests, and production-style build. Then exercise the main user journey in a browser. Check a narrow viewport, keyboard access, loading and error states, validation, sign-in and sign-out, and a fresh reload. Record what you actually tested and list what you did not.

Verify links, legal disclosures, contact routes, page titles, descriptions, canonical URLs, and social previews. Serve a sitemap and robots file consistent with the intended public domain. Structured data should describe visible facts. Do not add invented ratings, reviews, prices, or awards to make the page look authoritative.

Configure the domain deliberately

Macaly documents publishing to a free Macaly subdomain and connecting a custom domain on a paid plan. The domain purchase is separate. Follow the exact DNS values shown for your project rather than copying values from a blog post. Check both the apex and www address, redirects, and HTTPS after verification.

Choose one canonical public origin. Make internal links, sitemap entries, structured data, and social metadata agree with it. Keep a new preview out of your public launch communications until its content and disclosures have been reviewed. Domain registration and a green SSL indicator do not by themselves demonstrate that search engines have indexed the site.

Protect data and secrets

Use the supported secret store and confirm private keys are absent from the browser bundle. Test cross-account authorization and unauthenticated requests. Restrict administrative routes and avoid logging sensitive form contents. Review every public integration endpoint, especially those that spend credits or change records.

Back up the data you would be unhappy to lose. Understand what a backup includes: database rows, uploaded files, and configuration may have separate export paths. Test a restore in a safe environment. A backup that has never been restored is an unverified recovery assumption.

Make a rollback and monitoring plan

Know which release was last working and how to return to it. A code rollback may not reverse a database migration, payment, email, or external API side effect. Prefer additive, compatible changes when an existing application has users. Assign a person to check the launch and respond if the main workflow fails.

Inspect logs and failed requests after release, and keep a small operational runbook. For a reference site, check broken links and stale claims as well as uptime. No tool in this directory removes the need for ownership after launch. The practical goal is a service you can observe and recover, not merely a deployment that once succeeded.

Continue reading

Your next useful step.

• Vibe coding for beginners: the learning path
• Full-stack AI apps: architecture learning path
• Deploying AI-built apps: the launch learning path
• AI app builder costs: the buying learning path