Guide
From Claude Code to production
The first release gets your app online. The next release has to preserve the work people have already put into it. Use a small, explicit release process when Claude Code changes an app your team depends on.
Short answer
Test the update away from production using existing as well as new records. Review permissions and schema changes, record the exact commit, and confirm a recovery path before release. Then verify the affected workflow in production.
Use an environment that can reveal data problems
For AI-built business applications, a screenshot of the new screen is not enough. The test deployment needs its own database, representative records and sandbox integrations. An empty preview can hide broken migrations and access checks.
You can maintain a staging environment yourself, configure service previews such as Render’s Blueprint environments, or use an application platform that provisions preview data with the branch. AppHaven follows that last model; its production backup history supports recovery planning. This process still needs your review of the business rules.
Example: adding payment status to an invoice tracker
The request sounds small: let the team mark an invoice as paid. It touches the screen, the save endpoint, the database schema and reports. A preview with one new invoice may work even if older invoices disappear from the unpaid list.
Give Claude the business rules before it changes code: existing invoices must remain visible, amounts must stay unchanged, and only users allowed to edit an invoice may change its status. Those rules become the acceptance checks.
Build a release check from the business rules
| Scenario | What should happen |
|---|---|
| Open an invoice created before this change | It appears with the correct amount and a defined payment status. |
| Mark an invoice paid, then reload | Its status persists and its amount is unchanged. |
| Open the unpaid report | Paid invoices are excluded; older unpaid invoices are still included. |
| Try the update as a user without edit access | The server rejects it, even if the request bypasses the screen. |
| Submit the update twice | The second request does not create a duplicate payment or notification. |
Separate adding data from removing it
Ask for the migration plan in the pull request. Adding a status field should define what existing rows mean and whether older code can still run after the change. Run that migration on representative test data and check its execution time.
When replacing an old field, keep it during the first release. Move readers and writers to the new representation, verify the result, then remove the old field in a later release. That leaves room to revert the application without immediately needing to recover deleted data.
Release the reviewed change
Identify the exact revision
Check the preview’s commit against the pull request. A preview of yesterday’s commit is not evidence for the fix added this morning.
Review code and results
Inspect migrations, permission checks and external side effects alongside the acceptance results. If the diff is too large to review confidently, split it into smaller releases.
Check recovery readiness
Confirm the production backup window and record the last known working commit. Decide who can request recovery and how to reach them.
Merge through a protected branch
Use required review and restrict direct pushes. Deploy the production branch, or allow the approved merge to trigger auto-deploy.
Check production
Verify startup logs and the business operation you changed. Check an existing record as well as a new test case; monitor the app after the release.
If the release goes wrong
First establish whether the app is unavailable, showing wrong results, or actively changing data incorrectly. Stop the damaging operation or pause the affected workflow if necessary. Record the commit and incident time before more changes obscure the sequence.
Revert the application only after checking that the previous version can run against the current schema. A code rollback will not recreate deleted invoices or undo an email already sent. If data needs recovery, preserve the current state and coordinate a restore before overwriting it.
Make recovery actionable
Recovery request example
App: invoice-tracker
Deployment: production
Problem: the release overwrote payment status on existing invoices
Last known correct time: [date and time, including timezone]
Bad release commit: [commit hash]
Affected data: invoice payment status
New work since that time: [invoices/payments that must be preserved]
Files or external systems involved: [attachments/payment provider]
Please confirm the available recovery point and next steps before
replacing production data.Fill in the actual incident details. Do not include credentials or customer records in the request.
What AppHaven does during this process
AppHaven provides the preview environment, production backup history and deployment logs. The recovery documentation currently directs restores through support. Discuss a recovery exercise before a critical rollout, including how new work after the chosen restore point would be preserved.
Claude can help read logs and prepare a fix through the read-only agent integration. Keep the fix on a reviewed branch so investigating an incident does not turn into an unplanned release.
Common questions
Should every change follow this whole process?
Scale the checks to the change. A label edit needs much less review than a new payment workflow. Changes to data, permissions or external actions need explicit acceptance and recovery checks.
Can backups undo everything?
No. A database restore does not retract sent emails, reverse charges or restore files to every database timestamp. Identify those effects before deciding how to recover.
Keep improving the app your team relies on
Evaluate AppHaven’s previews and recovery process against the release checks your application needs.