Ship changes without breaking the product customers pay for
Make releases safer for an AI-built product with paying customers. Check critical journeys, control rollout and separate code rollback from data recovery.
Once people pay for the product, a release needs to preserve what they already rely on. Keep the change understandable, check the important customer paths and decide how you will recover before exposing everyone to it.
Make the release small enough to explain
You want to improve report generation, tidy the account screen and upgrade several dependencies. Shipping them together might feel efficient. If checkout stops working afterwards, however, you have several possible causes and several changes to untangle while customers wait.
Describe a release as one useful change with its affected customer paths. Separate unrelated work when that makes diagnosis and recovery easier. Small does not necessarily mean a tiny diff: a short configuration change can still alter access for every account.
For each release, record what will become possible, what existing behavior must remain and which parts of the system it touches. Include prompts, model choices, permissions and provider configuration. Those can change the product just as much as an application code edit.
Test the journeys that sustain the business
Choose the paths customers need to buy and receive value: signing in, getting the correct access, starting useful work, retrieving a result and returning to it later. Add the failure and recovery paths relevant to the change. A page opening successfully is not evidence that the whole transaction works.
Use disposable accounts and provider test modes where supported. Test both an existing customer with history and a new customer. A clean test account often misses permissions, older data formats and states that accumulated before the latest version.
Keep a short repeatable check for these journeys. It can combine automated assertions and an intentional browser review. The purpose is to catch a wrong result, missing permission or interrupted workflow before a paying customer finds it, not to maximize the number of tests on a dashboard.
Treat database changes as a separate release decision
Application code can often be redeployed from a previous version. The database may already contain new writes or a changed schema. Returning the code does not put deleted data back or make an old version understand a renamed field.
For a field change, consider an expand-and-contract sequence: add compatible structure, deploy code that can tolerate the transition, migrate existing data with checks, then remove the old structure only after it is no longer needed. The sequence must fit your product, including background workers and open browser sessions running older code.
Supabase documents versioned migrations and coordinated deployment. Ask to see the migration, its rehearsal on representative data, expected locking or load, and a recovery decision if it stops midway. A command that repairs migration history is not a command that reverses the underlying SQL.
Expose the change deliberately
For a meaningful behavior change, begin with an internal test account or a limited customer group when the product supports it. Make the selection stable enough that a customer does not bounce unpredictably between old and new behavior during one job.
Feature flags can separate deployed code from enabled behavior. AWS describes this as a way to control exposure and turn a feature off. But the flag must govern the relevant server work as well as the visible button. Hiding an interface does not undo work that has already been accepted.
Choose an observation period that includes the changed workflow. If a report takes time or a daily task runs overnight, a minute of quiet server metrics is not enough. Increase exposure based on the results of those journeys, not simply because the deployment system says complete.
Write the stop condition before release
Decide what would make you pause: customers receiving the wrong result, access denial after purchase, a rise in failed jobs or waiting beyond the promised window. Define who watches those signals and who can act. A vague instruction to keep an eye on it is easy to lose during a busy day.
Also decide which recovery action is safe. Turn off a feature, redeploy compatible code, pause new work or correct a migration forward. Restoring a database backup can lose later customer writes, so it needs a different assessment from reverting an application version.
Rehearse the likely recovery in a safe environment. Confirm the previous artifact is available, the required access exists and the current schema permits the old code to run. A rollback plan that depends on someone remembering how last month's build worked is not ready.
Check the deployed product, not just the build
After release, identify the exact version serving production and repeat the relevant customer journey. Verify the result and its persisted state, not merely the success message. AWS's safe-deployment guidance includes post-deployment testing because local success does not prove production configuration.
Watch the affected workflow through its full cycle and compare it with the previous behavior. Keep the release record close to your error and job history so a new problem can be connected to a specific change.
If you have stopped shipping because every improvement feels dangerous, start with one important path and one controlled release. That is a practical engineering problem. A dependable release process lets you keep improving the product your customers already chose.
Frequently asked questions
Does a successful build mean a product release is safe?
No. A build proves that the artifact was created, not that production permissions, integrations and customer journeys work. Check the exact deployed version and the affected journeys after release.
Can I roll back a database change by redeploying old code?
Redeploying code does not reverse database writes or schema changes. Plan compatible migrations and choose a separate data recovery action based on what changed and what customers wrote afterwards.
When is a feature flag useful?
It helps control when deployed behavior reaches customers and can disable a path when needed. It must govern the relevant server work, and it does not automatically undo jobs or data changes already performed.