Separate build success from user-visible success
A build process can generate valid files while a link still points to the wrong path. It can compile a form whose API endpoint is unavailable. It can also produce a page containing a placeholder value that was intended to be replaced by configuration.
Before deployment, identify the one user flow that matters most: opening a product page, sending an enquiry, viewing a record, or completing another meaningful action. After deployment, exercise that flow from its starting page. This gives a successful deployment a concrete definition beyond a green status.
Check direct routes and asset paths
Open the homepage and then visit an important nested route directly in a fresh tab. A site can work when you click through from the homepage yet fail when someone arrives from search or shares a deep link. Test the address people will actually use.
Check images, fonts, styles, and scripts. A missing asset can come from publishing the wrong folder, using a path that exists only on a developer machine, or expecting a build output directory that was not generated. Compare the requested URL with the actual output rather than guessing that the hosting service needs a restart.
Verify configuration in the correct phase
Some framework values are compiled into frontend JavaScript at build time. Changing a runtime environment variable may not alter those already-generated files. Other values are consumed by the running service. Identify which phase the application uses before changing configuration.
Use the platform’s supported secure configuration flow. Never put a secret into a public frontend value or paste it into a conversation. On build.host, redeploy after changing environment variables so the updated configuration can take effect through the supported deployment path.
Inspect the integration at the other end
A deployed frontend may call a database, API, authentication provider, or form service that needs its own setup. Check whether the endpoint exists, the expected account has access, and the service accepts requests from the deployed application.
Report the failing request, its status, and the action that triggered it without exposing private data. Build logs help when the build fails. Runtime logs help when an executable service fails after publication. Browser errors and the network panel help diagnose client-side failures. These are different sources of evidence.
Recover the existing project and verify again
Ask your agent to identify the existing project by name or live address. If a recent release caused the regression and an earlier deployment is available, a rollback may restore the code. It does not automatically undo changes in an external database or service.
After a fix, repeat the original failing action and check a nearby working flow. Keep the repair in the source project so the next deployment retains it. A useful report states what failed, what changed, which live address was checked, and what remains unresolved.