Collect product feedback without adding a support form

Someone finishes setting up your app and has one useful observation: “I couldn't tell whether that saved.” Asking them to describe their account, attach a screenshot, and pick a support priority can turn a small observation into work.

TinyFeedback by TinyScale gives that moment a smaller surface: a category and a plain-text message. It fits a question such as “What was confusing about setup?” It does not provide a private support conversation or a promised reply.

Ask about the screen the person just used

Put the widget near a nonessential part of your setup or settings page. Keep your main action available independently. Choose a prompt that helps someone describe the problem without requesting account details.

After completing the CLI download, checksum verification, and preview setup, configure the widget from that same project directory:

bun ./tinyscale-agent-v0.2.0.mjs feedback create --origin https://owned-project.example --name "Setup feedback" --prompt "What was confusing about setup? Please leave out personal information."

Replace the example origin with the exact HTTPS origin you own. Publish the returned script embed on that origin. The command requires a configured preview; it does not download the CLI or create the workspace for you.

The public form has no dedicated name, email, user ID, or attachment fields. Its message limit is 2,000 characters. This reduces what the form asks for, but free text can still contain personal information. Avoid claiming that anonymous-by-default collection makes every message anonymous.

Verify receipt before calling the integration finished

Submit a synthetic message: “Test feedback: the save confirmation was unclear.” The widget exposes the returned submission ID through tinyfeedback:received and its data-submission-id attribute. Verify it with the widget ID from creation:

bun ./tinyscale-agent-v0.2.0.mjs feedback verify --widget WIDGET_ID --submission SUBMISSION_ID

Replace both placeholders with those results. The verification path confirms receipt without returning the message body to the agent. Seeing the form on the page proves that it rendered; this step proves that a submission reached the service.

Understand a failed send

If sending fails, the widget shows a retry message and keeps the entered text. Retrying unchanged input in the same mounted widget reuses the pending submission key. Changing the text or remounting the widget is a different situation; this is not a guarantee against every repeated message.

Do not make successful feedback delivery a prerequisite for saving settings, creating a project, or leaving a screen. A collection failure should cost the feedback opportunity, not the user's completed work. The current integration has hard limits; inspect workspace status before diagnosing a limit as a broken form.

Keep the next step honest

After the synthetic result is verified, run workspace claim and let the human owner claim the same project in their browser. Preview lasts 72 hours; claim continues under Free limits and takes no payment. Keep the CLI's private .tinyscale state out of logs, model context, and source control.

Use this workflow to learn where instructions need improvement. A message is an observation, not a representative survey or proof of churn. For issue resolution requiring identity or a reply, offer your existing support channel separately.

Start with the complete TinyFeedback walkthrough, or inspect the current command reference.