Skip to content
Guide6 min read

Share a Firebase Studio Project With a Client

Give a client the result without asking them to click a link.

Hand a working Firebase Studio build to a client who will not click a hosting link, using a short video instead of a shared URL.

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

A client who is not technical does not want a link to a Firebase Studio preview or a hosting URL they have to find time to click, figure out how to navigate, and interpret without guidance. They want to know one thing: does the thing they asked for exist and does it work. A short recorded video answers that directly, in the order that makes sense, without asking the client to do any of the work of finding the relevant screen themselves.

GogoScreen takes the app's public URL and a one line hint about what to show, returning a narrated, edited MP4 in roughly two minutes, with zooms on clicks, cursor smoothing, dead air removed, and captions burned in. If the client's flow sits behind 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. The video is not a replacement for eventually giving the client real access if they need it. It is what closes the gap between finishing a build and the client actually seeing that it is finished.

The live preview inside the Firebase Studio workspace typically requires the viewer to have access to the underlying Google Cloud or Firebase project, since it runs inside the same authenticated environment the build happens in. Sending a client that link either does not work at all, because they lack project access, or requires granting them a level of access to the project that a simple review does not call for. Neither outcome is what the handoff needed.

Deploy the build to its public Firebase Hosting URL instead, the one meant to be reachable without any project credentials, and record from there. That URL is what an actual end user of the finished app would eventually use, which makes it the right thing to show a client deciding whether the build matches what they asked for.

This also avoids a more awkward outcome: a client who cannot get a link to load at all, retries it a few times, then quietly concludes the project is broken before anyone has a chance to explain that it was simply the wrong link. A video sidesteps that entire failure mode, since there is nothing for the client to click, load, or get stuck on.

What to send the clientWhy it worksWhy the alternative fails
A short video from the deployed URLShows the result with no setup required from themA workspace preview link often needs project access they do not have
A plain sentence of contextTells them exactly what the video provesAn unexplained link leaves them guessing what to look for
One focused flowAnswers their actual question quicklyA full tour buries the one thing they asked about

What should you check before recording?

Open the deployed URL in a private browser window and walk through the exact flow the client asked about. Confirm nothing interrupts it: no leftover placeholder content, no broken link, no state that only works because of a session left over from testing. A client watching a video that shows an error is worse than a client who has not seen anything yet, because now they have evidence of a problem instead of an open question.

  • Confirm the flow the client asked about still works end to end.
  • Remove or replace any placeholder content left from the initial build.
  • Prepare demo data that looks believable without using anything sensitive.
  • Decide whether the client needs the whole flow or just the result.
  1. Confirm what the client actually needs to see, not everything that happens to be built.
  2. Deploy the build to a reachable Firebase Hosting URL and prepare it with safe demo data.
  3. Record the flow, review it once, and send it with a plain sentence explaining what it shows.

How narrow should the video be?

As narrow as the client's actual question. If they asked whether the signup flow works, show the signup flow and stop there, rather than adding three other features they did not ask about. A broader video invites a broader set of questions and slows down the specific approval the client actually needs to give. Save the fuller tour for a moment when the client has explicitly asked to see more.

Write the one line hint the same way, naming the exact starting point, the action, and the result, so the render does not wander toward a screen the client never asked about. If the build has since changed since the original request, note that in the message accompanying the video rather than letting the video imply something that is no longer accurate.

What should accompany the video when you send it?

Send a short plain sentence alongside the video explaining what it shows and why. Something like "this shows the signup flow you asked about, from the homepage through to the confirmation screen" gives the client context before they press play, so they know what they are watching and what to check. Do not assume the video speaks entirely for itself, even a well made one, since the client did not build the app and cannot infer intent from footage alone.

If the render came back with an issue, a stale cache or an unexpected screen, do not send it hoping the client will not notice. Roughly one render in five needs a retry. Fix the underlying cause and record again rather than shipping a video that undersells finished work.

Timing matters here too. A client who has been waiting on an update is more forgiving of a short delay for a redone render than they are of receiving something that looks unfinished on first watch. Build a small buffer into whatever timeline was promised for the handoff so a retry does not turn into a missed deadline, and say so plainly if the timeline needs to move rather than letting the client find out only when the video does not arrive.

How does this compare to the other Firebase Studio review jobs?

Sharing with a client sits between two related jobs. The Firebase Studio portfolio demo guide is for showing the build to someone deciding whether to hire the builder, and the Firebase Studio app review walkthrough guide is for an internal reviewer checking the build against a brief before it ever reaches the client. This page assumes the build already passed internal review and the client is the audience now.

For the equivalent job on a different builder, see the Softr demo video guide, the Softr landing page video guide, and the Softr Product Hunt launch video guide. If the client review is really about a code change rather than a finished feature, the coding agent demo video guide is the closer match. If the flow the client is waiting on is itself a dashboard style feature rather than a customer facing action, the internal dashboard demo video guide covers picking the one metric view a stakeholder needs before trusting the numbers, a narrower version of the same scoping question this page asks about a client's flow. For choosing the frame a video opens on, the demo video poster frame guide is worth reading, and the web app walkthrough video guide covers a longer format for when the client needs more than one flow explained. Compare GogoScreen against a dedicated recording tool at GogoScreen versus Screen Studio, and if the build is launching to a waitlist rather than going straight to the client, the waitlist launch demo video guide covers that separate moment. See 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

Why not just send the client the Firebase Hosting link?

A link still asks the client to find time, open it, and interpret an unfamiliar interface on their own. Many will not, and the ones who do may focus on the wrong thing. A short video shows exactly what they need to see in the order that makes sense.

Can I share the Firebase Studio workspace preview directly instead?

Usually not without granting the client access to the underlying Google Cloud or Firebase project, which is more access than a client review needs. Deploy to a reachable Firebase Hosting URL and record from there instead.

What if the client only cares about one specific feature?

Record a short video focused on that one feature rather than a general tour. A narrow, accurate video answers their actual question faster than a broad one that makes them search for the part they care about.

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.