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.

When is a feedback widget a better fit than a support form?

Use a small feedback widget when you need an observation about a screen and do not need identity, attachments or a reply thread. TinyFeedback collects a category and a bounded plain-text message. Keep account-specific support in a separate channel.

Prefer your agent to handle setup? Use the TinyFeedback setup prompt, then return here for the details.

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 preview setup, configure the widget from that same project directory:

npx -y tinyscale@0.10.0 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:

npx -y tinyscale@0.10.0 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.

Common questions

Where should I place the feedback widget?

Choose a setup or settings screen where someone can describe a specific difficulty. Keep the widget optional and leave the main application action independent of feedback delivery.

Will retries create duplicate feedback?

Retrying unchanged input in the same mounted widget reuses the pending submission key. Changing input or remounting changes that situation; this is not a guarantee against all repeated messages.