A working preview is the beginning of the review.
Check the journeys, data, and details that matter before sharing your app.
Start with the complete journey
A homepage loading successfully is useful evidence, but it covers only one moment. List the main things a person must be able to do and perform each one in the running app.
Submit an empty form, enter an invalid value, follow a deep link, and refresh a detail page. Look for a useful response in every case. Check that links and buttons do what their labels promise.
Check data after the moment has passed
Create a record, change it, reload, and confirm the change remains. Sign out and back in when authentication is part of the app. Where possible, verify the same behavior in a second browser session.
BigBag has durable storage integration for project and application records, but the deployment must configure it. A success message alone does not prove data will survive a restart. Verify persistence against the storage setup you will actually use.
Try the boundary between two people
If your app has accounts or roles, use separate test users. Verify that one user cannot read or change another user’s private records by changing a URL or a request. Check responses as well as what the interface displays.
The builder’s own project ownership checks do not automatically prove that every generated business rule is correct. Internal notes, admin actions, bookings, and inventory need tests that match their particular risks.
Review small screens and failure states
Use the preview at desktop and mobile sizes. Make sure navigation, forms, dialogs, and important actions stay within reach. Navigate using a keyboard and check that the current focus is visible.
Then consider a slow request or an unavailable integration. A support app should still let someone read and update a ticket if an AI reply fails. A checkout should not report a completed payment because a button was clicked.
Publish, then check the public address
Use the workspace’s publish controls after reviewing the build. Open the resulting public address in a separate session, revisit a nested route, and verify that scripts, styles, and images load. A local bind address such as 0.0.0.0 is not a public destination.
Keep a record of the version you published and what you tested. Version history helps you inspect or recover earlier work, but it does not replace checking the deployed result. Capacity, backup recovery, payment safety, and specialized business rules need their own evidence before you make production promises.