Show the client the logged in app, without asking them to log in.
Turn a logged in Bubble workflow into a video a client can watch, when they will not create an account just to review the work.
See how it worksYour first 60 seconds of video are free, with a watermark. Verify your email to download it.
gogoscreen.com
1
Name the one decision
Name the one decision the client needs to make before recording anything.
2
Prepare the demo account
Prepare a demo account with data already populated, since a Bubble app usually needs a login.
3
Send it with the decision stated plainly
Send the video with the decision the client needs to make stated plainly in the message.
A client asked to review a build rarely wants a login. Even a client who is comfortable with software has better things to do than create an account, remember a password, and figure out an unfamiliar interface just to check whether one thing was fixed. A video removes all of that. It shows the logged in workflow directly, already narrated around the decision the client actually needs to make. The client's attention goes straight to the question they care about, instead of the mechanics of getting into the app at all.
This is a more common problem for a Bubble project than for some other builders, because a Bubble app is frequently built with a real database and user accounts from the start. The workflow worth showing a client is often the same workflow that only exists once somebody is signed in, which means the video has to bridge that gap rather than simply pointing the client at a public link. A link alone would ask the client to do the very thing a video is meant to spare them from doing in the first place.
Write down the one decision the client needs to make after watching, before recording anything. It might be approving a change, confirming a fix matches what they described on a call, or choosing between two options. Everything the video shows should serve that one decision. A broader tour of the app answers questions the client did not ask and buries the one they did.
Set up a demo account ahead of time with data already in it that supports the review, rather than opening on a blank new signup. A fresh account with nothing populated forces the video to spend its opening moments on setup instead of the thing the client actually needs to see. Use data that reads as plausible without resembling any real customer's information.
Prepare a demo account with data already populated before writing the hint.
Confirm the login itself completes without an unexpected step, such as a verification screen.
Start the recording from the logged in state, not from the signup flow.
Keep any names, numbers, or records free of real customer material.
A supplied login credential is encrypted, used for a single render, then deleted, which is the relevant handling here since this format frequently does need a credential just to reach the workflow the client wants reviewed. When a storyboard is planned first, the credentials are kept encrypted for that session and deleted at most two hours after their last use. Setting the account up a day ahead of the deadline, rather than the same afternoon, leaves room to fix anything that looks wrong before it becomes the client's problem to notice.
Name the starting screen, already logged in, the action under review, and the result the client should see. "From the client's dashboard, submit the updated request and show the confirmation" gives the render something concrete to follow, and gives you something concrete to check the finished file against afterward. Match the wording in the hint to terms the client already uses, not internal names from inside the build.
This matters more for a Bubble build than it might for a simpler app, because Bubble's own editor exposes names for elements, workflows, and data types that rarely match what a client would call the same thing. A workflow labeled with an internal shorthand in the editor still needs to be described in the hint the way the client actually talks about it, since the generator is following the hint's wording against the page structure it can see, not the label a developer chose while building the app.
Two habits keep a hint aimed at the client's actual question rather than the build's internal mechanics:
Describe the end state, not the button. "Show the request move from pending to approved" is something the generator can confirm actually happened. "Click the approve button" only describes an action that might or might not produce the result the client is checking for.
Write the hint before you record, not while narrating in your head as you click through the app. A hint drafted in advance keeps the one decision from the earlier step in view, and gives you a written record to check the finished render against.
Keep the hint to one or two sentences either way. A longer hint tends to describe more than a single decision can carry, and a video trying to answer two questions usually answers neither one clearly for the person watching it.
The order that gets to a clear client decision fastest:
Name the one decision the client needs to make before recording anything.
Prepare a demo account with data already populated, since a Bubble app usually needs a login.
Send the video with the decision the client needs to make stated plainly in the message.
GogoScreen returns a narrated, edited MP4 built from the hint, with zooms on the relevant clicks, cursor smoothing, dead air cuts, and captions. Review the narration against what actually happened on screen before sending it, since a mismatch there is one of the more common reasons a client comes back confused rather than with a clear answer.
Send the file with the decision stated plainly in the same message, rather than leaving the client to guess what they are meant to look for. "Here is the updated flow you asked about, let me know if this matches" gives them a direct prompt to respond to. If the reply that comes back does not line up with the video, check the flow again before assuming the client misunderstood, since the more common cause is a reply aimed at a screen the video never covered.
Roughly one render in five needs a retry, and time is used only when a render succeeds, so leave a little time before a deadline for a second attempt rather than sending the first file the moment it arrives.
Once a client signs off, the same build usually needs other purpose built assets. The Bubble portfolio demo guide covers showing the finished work to a broader audience, and the Bubble app review walkthrough covers the internal sign off version of this same handoff.
Why not just give the client a login to the Bubble app?
Most clients will not create an account, remember a password, and navigate an unfamiliar interface just to review one change. A video shows the same logged in workflow without asking them to do any of that.
Does the client need to see the account creation step?
Usually not. Start the recording from an already populated account so the video opens on the result the client is checking, rather than spending its opening seconds on a signup flow.
What if the client's reply does not match what the video showed?
Check the flow again before assuming the feedback is confused. It is common for a reply to target something the video did not cover, which usually means a second, narrower video is the fix, not a call to re-explain the first one.
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.
