Update a Live AI-Built Website or Web App Without Breaking It

Make Sure You Can Return to the Working Version

Before changing anything, make sure you can return to the version that is working now.

If the project uses GitHub, confirm the current live version is committed and pushed.

If it does not use Git, create a backup or export of the working project before continuing.

IMPORTANT

Keep any production database backup or recovery option available if your update will change stored data.

Describe the Update to Your AI Coding Assistant

Open the project in your AI coding assistant and describe the update you want.

Scoped Production Update

Describes one change to an existing production project, asks the assistant to identify up front whether it touches authentication, the database, environment variables, APIs, routes, build configuration, payments or storage, and to make only what the request requires — without deploying or pushing anything.

Make the following change to this existing production project: [DESCRIBE THE CHANGE] Preserve the current design, functionality, and production configuration unless the requested change genuinely requires modifying them. Before changing anything, identify whether this update affects: - authentication - database schema or stored data - environment variables - APIs or external services - routes or URLs - build or runtime configuration - payments - storage or uploads Make only the changes required for the request. Do not deploy, push, or modify production yet. When finished, give me a short summary of what changed and anything that could affect the live version.

Review the result before preparing the update for production.

Review the Changes for Production Risk

Before publishing the update, ask your AI coding assistant to review the changes specifically for production risk.

Pre-Deployment Risk Review

Reviews everything changed since the current live version — build, tests and type checks, dependencies, environment variables, permissions, migrations, API configuration and routing — fixes only genuine deployment blockers, and finishes with a deploy/hold verdict, the risks, and how to roll the update back if it fails.

Review the changes made since the current live version and determine whether they are safe to deploy. Check: - the production build - relevant tests and type checks - runtime or dependency changes - environment-variable changes - authentication and permissions - database migrations or schema changes - API and external-service configuration - routing and asset paths - anything that could break existing production functionality Pay special attention to destructive database changes, removed environment variables, changed API contracts, and anything that cannot be easily rolled back. Fix only genuine deployment blockers. Do not deploy or push anything yet. Finish with: 1. Safe to deploy 2. Requires manual action before deployment 3. Risks I should know about 4. How to roll back this update if it fails

Continue only when the production build and required checks pass.

Publish From the Existing Production Project

Publish the update using the existing production project.

If your project uses GitHub automatic deployment:

Review → Commit → Push → Automatic Deployment

IMPORTANT

If you deploy manually, update the existing deployment instead of creating a separate production project.

Watch the Update Reach Production

Watch the build and deployment logs until the new version is live.

If the update requires new environment variables, database migrations, or external-service changes, apply them in the correct order identified in Step 3.

Test the Production Version Immediately

Test the production version immediately after deployment. Check:

The updated feature works

Main pages and routes still work

Authentication still works

Forms and important user flows work

Database features behave correctly

APIs and external services still respond

No important assets are missing

No new critical runtime errors appear

If Something Breaks

Stop making additional changes.

IMPORTANT

Return to the last known working version using your hosting rollback, Git history, or saved backup.

Then use the new production error or logs to diagnose the failed update before trying again.

Your update is complete only when the new feature works and the important existing features still work.