Editorial correction, 21 September 2026: an earlier article at this address described a purported Claude Code incident using details and records we could not substantiate. We have removed that reporting. This replacement discusses general release practices and does not assert that the earlier incident account was accurate.
Publishing software makes a selected set of files available to someone else. That sounds obvious, yet teams often review the source changes more carefully than the actual package or deployment those changes produce.
For a small business shipping a website, tool, or package, a short release check can catch mistakes that are hard to reverse after publication. The check should inspect the deliverable, not just the intention behind it.
Review what will be distributed
Build the release using the intended configuration and inspect the output. Look for files that do not belong: internal notes, exports, development fixtures, credentials, private images, or customer data.
If you publish an npm package, the official npm pack documentation describes the command and dry-run option. Use the appropriate inspection workflow for your package manager and check the exact version’s behaviour.
For a website, inspect public assets and downloadable files as well as rendered pages. A file can be reachable even if there is no prominent link to it. Removing a navigation item is not an access-control mechanism.
Make the expected public contents explicit. An allowlist can be easier to review than a growing list of things someone remembered to exclude.
Keep credentials out of source and browser code
Store secrets using the environment or secret-management mechanism appropriate to the deployment. A value that reaches browser JavaScript should be treated as visible to visitors, regardless of how obscure its variable name looks.
Enable relevant repository protections where available. GitHub’s push protection documentation explains how supported credential patterns can be blocked before they enter a repository.
Scanning is a helpful control, not proof that every possible secret has been found. Review the actual changed files and configuration. Never paste a credential into a public issue or screenshot while asking for help.
If a credential is exposed, removing the file is not sufficient. Revoke or rotate it through the relevant provider and investigate what it could access.
Decide how source maps are handled
Source maps can help diagnose production errors. They can also reveal source structure that a team did not intend to publish. The right choice depends on your debugging setup and what the maps contain.
Ask the developer whether source maps are public, uploaded privately to an error-monitoring service, or excluded. Verify that the build matches the decision.
Do not rely on hiding source code to protect secrets or authorise actions. Those responsibilities belong in the system’s security design regardless of whether a source map is available.
Test access from outside the team
Open the deployed site in a session without administrator privileges. Check which pages and files are public, which actions require authentication, and whether restricted data remains inaccessible.
Use controlled test accounts and data. Do not probe systems you do not own or attempt to retrieve real private information merely to prove a point.
Test the critical business flow, including forms, payments if applicable, and notifications. A build finishing successfully does not prove the customer journey works in the deployed environment.
Prepare a recovery path
Record the release identifier, deployment address, test results, and previous working version. Know who can roll back and which changes, such as database migrations, may need additional handling.
Make failures visible without exposing sensitive data in logs. Decide who receives alerts and how the team will communicate if the release needs to be withdrawn.
A release process does not have to become a large bureaucracy. For a small site, a concise checklist with real evidence can be enough to improve consistency. Our launch checklist covers the customer-facing basics, while a business website project should include a handover explaining how the site is deployed and maintained.