Your AI app works in preview. Check the published version.

Your coding agent says the change is ready. The preview shows the new booking flow. You open the link you sent your client and see the old one.

Before asking the agent to fix the app again, compare the same short flow at both addresses. Record what happens, identify the version behind each URL, and check whether they use the same data.

That gives you a way to separate a feature bug from a change that has not reached the published app.

Preview and published URLs can serve different builds

In an AI app builder, the chat, preview and published site can show different stages of a change.

For example, Lovable’s preview documentation describes the preview as your latest work. The published app is a snapshot that changes when you publish. Each draft also has its own preview address.

A walkthrough in one view establishes what happened there. To review what visitors see, repeat the flow at the address they use. Rill can record both checks, but the recording alone cannot identify which source revision reached the browser.

Name the target before recording

Choose one changed behavior. On a booking page, that might be selecting a service and checking its duration. Stop before confirming a booking.

Keep these details beside each clip:

• Exact URL and route. Remove secrets and access tokens from anything you share.
• Environment: local app, builder preview, draft, deployment preview or published site.
• Version: commit, deployment ID or builder version, where available. Write “not verified” if you cannot confirm it.
• Starting state: account or test role, relevant feature flags, test data, browser and viewport.
• Expected result, check time and stopping point.

A URL can serve a different build tomorrow. Keep the deployment reference your hosting system already provides; you do not need to build a new version-label feature for this check. A branch name alone does not confirm what the browser loaded.

Check whether the preview shares live data

A preview address does not guarantee an isolated database. Lovable’s preview docs explicitly say the preview and published app share backend data. Check your own setup before testing a write.

For a read-only comparison, stop before creating a record, sending an email or triggering payment. If the feature requires a write, agree on the test account, permitted action and cleanup first. Use isolated test data where available. A fake customer name can still create a real booking.

Sign in before recording when appropriate, keep customer records and credentials out of view, and inspect the capture before sharing it.

Compare the same booking flow in both versions

This is a fictional example. The app, versions and results illustrate the method; they are not recordings of a real customer’s app.

A studio asks its coding agent to change the duration of “Portfolio review” from 30 to 45 minutes.

The reviewer records the preview: open the booking page, select Portfolio review, read the duration, stop before confirming. It shows 45 minutes.

They repeat those steps at the published URL in a fresh signed-out session. It shows 30 minutes. Both checks use the same service and desktop viewport, and neither submits a booking.

The review note separates the evidence:

Observed: The preview shows 45 minutes. The published page shows 30 minutes for the same selection.

Verified separately: In this example, the hosting record identifies deployment A as published and version B as the candidate. That supports a version mismatch; the clips alone do not establish its cause.

Next step: Confirm whether B is intended for release and publish through the normal approval process. After release, repeat the public check and attach the new clip with its deployment reference.

Not checked: Booking creation, persistence, mobile behavior, permissions or payments.

Without the deployment record, keep the cause open. Configuration, cached content, account state or data could also explain the difference. Compare those details before rewriting the feature.

Record the comparison with Rill

If you are reviewing the change yourself, record your screen with Rill. Capture each flow with optional narration. Say which target you are checking and what you expect to see. Manual screen recordings do not automatically include console or network diagnostics.

If your coding agent already drives a supported Chromium browser, use Rill’s agent recording guide. Rill captures the browser run and supported diagnostics while the agent performs the check.

Keep the clips short and use the same starting state and stopping point. If you change the account, test record or viewport, include that in the note.

Review Rill’s capture and sharing details before sending a link. Local agent recordings receive unlisted share links, including when connected to an account. Anyone with an active share link can view the recording and included diagnostics. Rill does not mask sensitive content in the video.

Give your agent a focused comparison prompt

Replace the placeholders with your targets and one flow:

Review only. Do not edit code, publish, change configuration or submit forms.

Compare [preview URL + version if verified] with [published URL + deployment if verified].

On each target, start [state], perform [steps], and check [expected visible result]. Stop before [restricted action]. Use approved test data only. Confirm the target and data boundary before testing; ask if unclear.

Record both flows using the existing approved Rill setup. Verify playback and return each link with its access and expiry details.

Report what you observed, which versions you verified separately, and what remains unknown. Do not infer a version mismatch from appearance alone.

If the same verified version behaves differently at the two addresses, investigate the relevant configuration, account state and request behavior one at a time. Keep the original clips so you can compare the next check with the discrepancy you started with.

For a fix that changes behavior, use the before-and-after recording guide to repeat the failing steps after the change. Browser recordings support that review alongside code review, automated tests and security checks.

Pick one change you are reviewing today. Record the flow, name the target beside the clip, and repeat it at the URL your users will open.