Keep your project online after launch

Write the note your future self will need

Record the public address, source repository, host, production branch or publishing process, domain registrar and contact inbox. For each service, name its purpose and account owner. Include recovery instructions or a reference to your password manager, not passwords, tokens or backup codes in the document.

Add the application’s basic shape: which code runs in the browser, which functions run on the server, where durable data lives and which external services it calls. If an agent helped build it, ask for this explanation before the session ends. “It uses a database” is not enough; identify the project and the kind of records it stores.

Scroll to see all columns →

Publish a small change and locate rollback

Make a harmless change, run the relevant checks, publish it and confirm the result at the same public URL. Record the deployed version or commit when available. Open a direct inner link and finish the main task. A deployment marked ready can still have the wrong environment setting or a broken runtime dependency.

Find the previous known working deployment and read the rollback process. Understand that restoring application code may not undo a database change or reverse already sent email. For changes involving stored data, use a migration and recovery approach appropriate to that data, rather than treating every problem as a one-click code rollback.

Separate source backup from user-data recovery

A copy of the code does not contain database records, uploaded files or account configuration. Decide what would be painful to lose, where it is stored and what recovery your provider actually includes. Check the current plan and settings; do not assume that a provider logo means backups are enabled.

When the project stores valuable data, test a restore into an appropriate separate environment before relying on the process. Verify the restored records and the application behavior. Keep backup access restricted. For a small tool with no server-side user data, document that simpler situation instead of adding a database solely to create a backup task.

Check a few useful things regularly

Choose a cadence based on how the product is used and the consequences of failure. For an actively used small project, a short routine can include opening the live address, finishing the key task, reviewing recent errors, checking contact messages and inspecting service usage. An unattended failed form can matter more than a cosmetic issue.

Watch domain renewal, payment method validity and provider notices. Review dependencies before applying updates, use a preview when available and repeat the relevant checks after the update. Blind automatic changes can break an application; ignoring updates indefinitely creates a different problem. Keep an explicit owner for the decision.

• Check the live useful action and a direct inner URL.
• Review failures, contact messages and relevant delivery problems.
• Inspect service usage and spending controls.
• Check domain/account renewal and recovery access.
• Apply necessary updates through a tested release path.

Use a small incident routine

When something fails, establish what is affected and which version is live. Reproduce the issue with a safe account and note the time, steps and expected result. Check provider status and recent changes. Avoid making several unrelated production changes at once; that makes it harder to understand what restored the service.

If a known previous version is safe to restore, follow the documented path and verify the main task afterward. Communicate a meaningful limitation through the appropriate product or contact route. Do not announce full recovery based only on a dashboard turning green. The person’s task is the final check.

Create an operations handoff for this project without revealing secrets. Include public URL, source location, production update route, hosting/domain account owners, runtime and data dependencies, meaningful health checks, budget controls, backup/restore status and rollback limits. Label each item verified, configured or untested. Give a short failure-response sequence and list the evidence needed before calling the service recovered.

Make the project understandable to someone else

Keep the operations note with the source and update it when services change. Record a short release note for a meaningful change: what visitors experience differently, what was checked and any limits. This helps a future collaborator or agent continue without reconstructing the project from scattered dashboard tabs.

If you decide to stop maintaining it, make that decision visible. Preserve a useful archive or source link when appropriate, stop unnecessary paid services and handle user data according to the commitments you made. A clear retired project page is more useful than a broken interactive experience that still asks people to trust it.