Guide7 min read

Firebase Studio App Review Walkthrough Video

Prove the build matches the brief with the deployed app, not the workspace.

Give a reviewer one recorded flow that proves a Firebase Studio build matches the brief, using the deployed app, not the workspace preview.

See how it worksYour first 60 seconds of video are free, with a watermark.
Verify your email to download it.

A Firebase Studio review walkthrough exists to close the gap between a status update that says a feature is done and actual proof that it works. A reviewer reading "the export feature is finished" cannot tell from that sentence whether it means the button produces a correct file or that someone hoped it would. A short video of the export actually happening, ending with a file the reviewer can see, removes that ambiguity in a way a written update cannot.

GogoScreen produces this from a public app URL and a one line hint, returning a narrated MP4 in roughly two minutes, with zooms on clicks, cursor smoothing, dead air removed, and captions burned in. If the flow needs a login, a demo account can be supplied, encrypted, used for a single render, then deleted. When a storyboard is planned first, the credentials are kept encrypted for that session and deleted at most two hours after their last use. This is proof of one flow that was checked, not a claim that everything in the build was reviewed or that any render is guaranteed to succeed on the first attempt.

Why record the deployed app instead of the workspace?

The workspace preview inside Firebase Studio is tied to whoever has access to the underlying Google Cloud project, which is often just the person building the app, not the reviewer waiting to approve it. Sending a reviewer that link either fails outright or means granting them project access far beyond what a review requires. Deploy the build to its public Firebase Hosting URL and record from there so the reviewer sees exactly what an eventual end user would see.

This also has a side benefit worth keeping in mind. A flow that only behaves correctly inside the development workspace, relying on environment variables or test configuration that does not carry over to the deployed version, is not actually finished even if it looks finished in the workspace. Recording from the deployed URL surfaces that gap before the reviewer does.

Review requirement	Why the deployed URL satisfies it	Why the workspace preview does not
Reviewer can watch without extra access	Public hosting URL needs no project login	Workspace preview needs the same Google account as the build
Confirms the shipped behavior	Shows what an end user will actually see	Can differ from the workspace due to environment differences
Reusable evidence for the brief	A durable recorded artifact tied to a specific request	Not a stable, shareable reference afterward

What exactly should the recording prove?

Reread the specific line in the brief before picking the flow, not the app's general feature set. If the brief said "an admin can approve a submission and it appears in the public list," the walkthrough needs to show precisely that, starting from the admin's action and ending at the submission appearing publicly. Anything the walkthrough shows beyond that specific request is extra, and anything it fails to show that the brief asked for leaves the review incomplete.

Match the flow in the recording to the exact wording of the brief.
Start the recording at the state right before the described trigger.
End the recording once the described result is visible, not sooner or later.

Reread the brief and choose the one flow that proves the specific request was met.
Prepare the deployed app at the state right before the trigger, using safe demo data.
Record the walkthrough and note anything from the brief that is still open or unresolved.

Which flow actually proves the brief was met depends on what the build is. If the app under review is a client portal, the client portal demo video guide covers picking the one status a client actually logs in to check, which is the same kind of specific proof this walkthrough is built around. If it is a CRM, the CRM demo video guide covers picking one deal or contact that moves through a real action instead of touring every tab. If it is an internal dashboard, the internal dashboard demo video guide covers picking the single metric view that answers the question the dashboard was built to answer.

How should the app be set up before recording?

Get the deployed app into the state that sits right before the described trigger, using data prepared ahead of time rather than recording the setup itself. If the flow depends on a record already existing or a user already signed in, arrange that before requesting the render so the recording opens directly on the relevant moment. A reviewer does not need to watch account creation before seeing the feature they are actually reviewing.

If a real client's data would normally be present at this point in the flow, substitute invented but believable data instead. A reviewer evaluating whether the logic works does not need to see anything sensitive to reach that judgment, and using invented data avoids any question later about whether something private ended up in a recorded file.

Keep a short written note alongside the invented data explaining what stands in for what, in case a second reviewer joins the process later and needs to understand why a name in the video does not match anything in the real project. This is a small habit, but it saves a confusing conversation weeks later when nobody remembers which parts of a recorded flow were staged for the review and which were genuinely part of the app's behavior.

What happens when the walkthrough reveals a problem?

Sometimes preparing for the recording surfaces the actual issue: the flow does not do quite what the brief described, or it works in the workspace but not on the deployed URL. Do not paper over that with a hint that steers around the broken part. Note the discrepancy plainly, alongside whatever partial evidence does exist, and treat the review as incomplete rather than approved. A walkthrough sent to make a problem look smaller than it is undermines the reviewer's ability to trust the next one.

Roughly one render in five needs a retry regardless of whether the underlying app is working correctly, so build a small buffer into any review deadline rather than assuming the first render will always come back usable.

Treat a failed or retried render as a normal part of the process rather than a sign that something is wrong with the build itself. The two are unrelated. A perfectly working flow can still need a second render attempt, and a genuinely broken flow can occasionally render cleanly and show the mismatch anyway. Judge the app on what the video actually shows once it comes back, not on how many attempts it took to get there.

Where does this fit with the rest of the review process?

This walkthrough usually comes after an internal check and before the build reaches a client or the public. The Softr demo video guide, Softr landing page video guide, Softr Product Hunt launch video guide, Softr share with a client guide, and Softr portfolio demo guide cover the comparable stages on a different builder platform, useful for seeing which stage of review a given video is meant to serve, since a portfolio entry, a client handoff, and an internal review walkthrough are three distinct jobs even when the underlying app is the same. The AI agent README demo guide is a related documentation asset for a technical reviewer who wants a written companion to the video. For a build produced largely by an autonomous coding agent rather than a person working directly in the editor, the AI agent feature walkthrough guide covers the equivalent proof for a single capability, and the agent handoff demo video guide covers the recording that follows once a reviewer has signed off and the work moves to whoever owns it next.

If the build in question came from a generated prompt rather than manual work in the editor, the prompt built app demo video guide and the AI agent landing page demo guide cover that framing more directly. For a flow that only exists behind a login, the logged in app demo video guide covers the specifics of that setup, and the AI agent demo video prompt guide covers writing the one line hint precisely enough to match what the reviewer is actually checking. Compare GogoScreen against a dedicated recording tool at GogoScreen versus Loom, check pricing for plans and top ups, browse the full guide library and the comparison pages, or start from the GogoScreen homepage for the URL and hint workflow itself.

Clarifications

Before you start

Should a Firebase Studio review walkthrough be recorded from the workspace or the deployed app?

Record it from the deployed public URL where possible. The workspace preview typically requires the same Google account access as the build itself, which the reviewer may not have and should not need for a review.

What should the walkthrough prove?

That the specific workflow described in the brief runs end to end and produces the result the brief described, not that the app generally looks finished.

Does a review walkthrough replace reading the code?

No. It replaces asking a non technical reviewer to read the code or click through the app themselves. A technical reviewer may still want to look at the implementation separately.

Paste a URL, describe one flow, and get a demo video of your web app.

Your first 60 seconds of video are free, with a watermark. Verify your email to download the video.

View pricing Read the guides