When the app works on my laptop, I want to get it online. But the live version has a different domain, configuration, network and people who won't use it exactly as I do.
These are the checks I want to finish before calling a JavaScript app ready. They reduce avoidable mistakes; they don't guarantee a release without bugs.
Build the version that will be deployed
Use the project's configured production build. If its scripts define it, that may be:
npm run buildRead the errors and relevant warnings. Preview the production build where the framework supports it, rather than relying only on the development server.
Check configuration and secrets
Compare the variables the app reads with the values in the correct hosting environment. Check whether a rebuild is needed after a change.
Public frontend configuration is visible to visitors. Private credentials and privileged keys belong on the server.
Test login and permission separately
On the production domain, try sign-up, sign-in, sign-out, recovery and confirmation links where used. Check expired sessions, refreshes and protected routes. Confirm the provider's redirect settings.
Then use two normal accounts to test data access. One account must not read or change another account's private records. The server and database must enforce the intended permissions.
Remove development shortcuts
Search for mock data, test IDs, localhost URLs, temporary bypasses and logs containing private information. Terms such as TODO, FIXME, dummy and console.log can help find candidates. Inspect each result; it isn't automatically a mistake.
Check failures and slow connections
The interface needs a clear message and a safe next step. Keep detailed diagnostics in suitable logs with secrets and unnecessary private data removed.
Test slow requests, interrupted submissions and repeated clicks. Make sure important operations cannot produce duplicate results simply because somebody tried again.
Use a phone and inspect the browser
Check forms with the keyboard open, menus, modals, long text, tap targets and horizontal scrolling on a real phone.
Inspect the console and Network panel on the live site. Investigate application errors, failed requests and unexpectedly large files.
Review performance and public-page information
Resize and compress media, delay appropriate off-screen content and examine what holds up the first useful screen. A score can guide investigation, but the actual journey matters.
For public pages, check the title, description, headings, canonical URL and relevant sharing metadata. Review robots settings and sitemap coverage. Keep private areas protected; hiding them from indexing is not access control.
Complete the main journey
Start like a new user and go through the action the product exists for. Don't skip steps because I know where they lead.
Then prepare a recovery plan. Know the previous release, the data changes and whether a rollback is safe. Database changes may need their own recovery approach.
I want to ship, not keep polishing forever. This checklist helps me check the assumptions before asking somebody to depend on the app.
A release record to keep beside the checklist
A checklist becomes more useful when I attach results to the exact version being released. This blank record is designed for a small JavaScript app. Fill it with observed results; an unchecked box is not a pass.
Release date: Commit or version: Preview URL: Change being released: Build command used: Build result and relevant error: Main journey tested: Device and browser: Signed-out behavior: Signed-in test account behavior: Second-account access check, where relevant: Invalid input result: Slow or failed request result: Reload and stored-result check: Configuration names checked (no secret values): Remaining failures or checks not run: Previous working version: Rollback route: Decision and reason:
For each check, write passed, failed or not run, with a short observation. “Build passed” and “checkout verified” answer different questions. If a provider test mode was used, record that instead of presenting it as a live payment result.
Read the project's package scripts before choosing commands. Use its documented build and test commands; a copied command from another framework may not apply. Record the command that actually ran, its result and the version being checked.
After deployment, repeat the main journey on the public URL. Confirm that the expected deployment is the one being served and that private configuration did not become visible in browser output. If the public journey fails, keep the evidence and follow the documented rollback route rather than stacking unrelated fixes onto production.