Get help with a no-code app builder

Describe the builder workflow

Identify the builder, page or element you are editing, and the sequence that led to the problem. State the intended behavior and the behavior you observe. For example, a marketplace form should create a test listing when submitted, but the preview shows no confirmation. Name the selected element and event, and include exact error text or configuration values in chat when available.

Tell the assistant what kind of help you need: locating a visible control, understanding a builder setting, comparing a preview, or deciding what evidence to check next. A narrow goal is easier to act on than “fix my app.”

Share the editor and result

On desktop, select the builder tab or application window in the browser's screen-sharing chooser. Show the relevant editor panel and preview together if that is practical; otherwise capture them separately so labels remain legible. Remove unrelated account or customer information from view. Verify the chosen screen before requesting a still image.

For any builder, first show which element or workflow stage is selected and the relevant visible settings; then capture the preview state after the same reproduction action. If the editor and preview cannot both be read clearly, request separate stills and label which is which. A preview symptom does not prove that the underlying workflow or data is correct. The assistant sees only the chosen pixels, not the project's database, permissions, or hidden settings. A browser chooser may require you to select a different tab when moving between editor and preview.

Make a guided change and recheck

Ask the assistant to describe the selected element, visible property/workflow context, and preview result separately, and point out which control or label is uncertain. Follow only the change you choose to make in the builder. After saving or previewing, capture the resulting state and compare it with the stated expectation. For a multi-step workflow, record each meaningful stage separately: selected element/settings, reproduction action, preview result, and final data or behavior verified in the builder's own test tools.

If a button now shows confirmation but the test record is missing, stop comparing button appearance and inspect the builder's debugger, logs, or data records. That changes the question from layout to behavior. Keep a short checkpoint in the conversation: selected element, change tried, expected result, actual result, and next unresolved question. Fresh screenshots do not fix a conversation's context limit or guarantee that an assistant remembers earlier decisions.

Use native project and data evidence

Screenshots cannot prove that a workflow is configured correctly, that permissions are safe, that data is accurate, or that an app works across users and devices. Use the builder's test tools, logs, project export, database records, and access controls for those checks. Paste exact formulas, queries, error messages, or configuration snippets directly when the assistant needs to reason about their contents.

LetItSee does not click controls, edit the project, publish changes, or monitor the app. Each screenshot is requested by you, and you choose the visible screen. Treat the assistant as a guide to your next investigation and verify the resulting behavior in the builder itself.

Set up without starting a capture

Set up your MCP client with the full tool reference. The separate capture page can replace the active capture page for your account. It does not take a photo by itself. When your source is ready, try:

Example to adapt: First capture the builder editor with [element/workflow stage] selected and [relevant visible settings] in view. Then, after I run [reproduction action], capture the preview showing [expected versus observed result]. Keep editor evidence separate from preview behavior; do not infer hidden workflow or database state. Suggest one check and wait for me to try it. I will verify records and permissions in the builder's own tools.