Your user points at the screen.Your team resolves it.
Paste one line into your product and a feedback button shows up. Bug, idea, interface or wrong data: reporters click the element, write what happened and send. You get the marked screenshot, the CSS selector, the console errors and the failed requests, and you decide what to do with it: triage in the dashboard, send it to your tracker, or hand it to your agent over MCP.
No credit card. 20 beta seats; after that, a waitlist with a launch discount.
The report you get today
Every team that collects user feedback knows these sentences. Each one costs a full round trip just to find out where to look.
What you receive
- “it doesn't work”
- “got an error at checkout”
- “a filter here would be nice”
- “this number is wrong”
What Clixy delivers
- Category
- Bug
- Element
- [data-clixy-id="finalizar-compra"]
- Page
- /checkout
- Console
- TypeError: cannot read property total of undefined
- Network
- POST /api/checkout returned 500 in 412ms
- Browser
- Safari 18 on macOS, viewport 1440x900
Three steps
From snippet to commit, without leaving what you already use.
- 01
Paste one line
Works on any site: React, Vue, Angular, Rails, WordPress. The widget assumes nothing about your code, and its styling stays inside a Shadow DOM, neither inheriting nor leaking CSS.
<script src="https://app.clixy.app/w.js" data-key="pk_live_..." async></script> - 02
Your user points and describes
The button opens a panel in the reporter's own language. They pick a category, click the element that broke and write what happened. The widget collects the rest on its own.
- 03
The report goes where your team works
It lands in the dashboard with everything attached, and from there it goes whichever way you prefer: triage with status, priority and assignee; an issue in GitLab or GitHub, by category and by page; or your agent reading it all over MCP. The three paths coexist, and none of them is required.
claude mcp add --transport http clixy https://app.clixy.app/mcp/ \ --header "Authorization: Bearer sk_live_..."
What travels with every report
None of this is typed by the reporter. The widget collects it while the person uses your product, and sends it in the same payload.
Screenshot with the spot marked
The capture is cropped around the element they picked, with it highlighted. Password fields and anything you tag with data-clixy-mask come out blurred.
The element CSS selector
It prefers the attributes you already use: data-clixy-id, data-testid, id. That is what lets you find the reported component in your code.
Console errors
The hooks install on page load, not at report time. The error that explains the bug almost always happens minutes before the person decides to complain.
Failed requests
Method, URL, status and duration for anything that returned 4xx, 5xx or never answered. Tokens in the query string are stripped before leaving the browser.
And the team works on it right there
Status, priority, assignee and internal comments. A list with filters or a board to drag between statuses, with roles for whoever joins by invitation. None of this needs an AI agent: it is the dashboard the team uses day to day.
Your team testing never reads as a customer complaint
Every report is born knowing where it came from. What the team reports from localhost or staging lands in a separate context, with its own metrics. The dashboard opens on production: feedback from the people actually using your product.
Nothing to configure on localhost
Turn local origins on and development feedback is classified from birth. Staging is a mark on the registered origin, and everything else defaults to production.
Metrics that do not lie
A bug QA tested ten times never shows up as ten unhappy customers. Each context counts only its own, in the list, on the board and in the numbers up top.
The agent separates too
The MCP tools filter by environment and default to production, because that is the report your agent should prioritize. The team one is a parameter away.
Feedback becomes an issue where the team already works
Connect GitLab or GitHub and the report opens an issue with the whole context in readable markdown, not in a JSON blob. Whoever fixes it reads the picked element, the console and the failed requests without leaving the repository.
- GitLab
- GitHub
Two way, for real
Close the issue in the tracker and the feedback closes here. Reopen it and it reopens. The reflection acts on the transition and not on the current status, so Clixy never reopens the issue your team closed by hand.
Each report in the right repository
The routing rule decides by the category of the report, by the path of the page where the problem showed up, or by both. The checkout bug goes to the checkout repository, the idea goes to the ideas one.
Without erasing your team work
Writing labels starts from what the issue already has: the ones someone applied by hand stay there. Every issue created carries a Clixy marker, so you can find everything that came from here later.
Your agent reads the feedback
Clixy exposes an MCP server. Connect Claude Code, Claude Desktop or Cursor to your account and the agent starts seeing the reports with their full technical context, without you copying anything.
List the open interface bugs from this week.
Three are open. The most reported is the checkout button: four reports, all with a console TypeError pointing at an undefined total on /checkout.
Fix the first one.
The selector is [data-clixy-id="finalizar-compra"]. I found the component in Checkout.tsx: the total is read before the cart loads. Fixed it and marked the feedback resolved.
list_projectsThe account projects, with the count for eachlist_feedbackSearch by status, environment, category, priority or textget_feedbackBrings element, console, network and screenshotupdate_feedbackChanges status and prioritycomment_feedbackRecords an internal comment on the reportfeedback_statsVolume by status, category and page
Details that matter
The widget runs inside your product. We treat that with the care it deserves.
13.9 kB
on load
That is what enters on every visit, already compressed. The screenshot library weighs more than that and is only fetched if someone asks for a capture.
Shadow DOM
full isolation
Your site's CSS never reaches the widget, and the widget's never leaks into your page. Tested against a stylesheet that rewrites every button in the document.
No IP
no personal data
Whoever reports a bug is not a Clixy user and consented to nothing. We store a hash of the address to limit abuse, never the address.
Fixed origin
the key alone is not enough
The public key sits in your HTML, and that is by design. What authorizes sending is the origin list you register, not the secrecy of the key.
Pricing
Everything is open during the beta.
Beta
Free
for as long as the beta runs, for the first 20 accounts
- Unlimited projects and feedback
- Screenshot, console and network on every report
- MCP server included
- Team with roles and invitations
- Dashboard in Portuguese and English
There will be a paid plan once the beta ends. Whoever joins now gets advance notice, and nothing starts being charged without your agreement first. After the 20 seats, new signups join the waitlist and get a discount at launch.
Questions
Does the widget slow my site down?
It loads asynchronously and takes 13.9 kB compressed. The screenshot library, which is the heavy part, is only downloaded when someone triggers a capture, so most visits never pay that cost.
What if someone copies my public key from the HTML?
The key identifies the project, it does not authorize sending. Only the origins you register can send feedback with it, and a request without an origin header is refused. There is also a rate limit per address and per project.
Does the screenshot capture sensitive data?
Password fields are blurred automatically. Any other element is blurred if you tag it with data-clixy-mask, which covers data only you know is sensitive. Capture can also be turned off per project.
Is Clixy only for bugs?
No. A project starts with four categories, bug, interface, wrong data and idea, and you can change whichever you want. They all arrive with the same technical context and go through the same triage, and the category is one of the criteria that decide which repository the issue goes to.
Do I have to use MCP?
No. The dashboard stands on its own: list, board, triage, priority, assignee and comments. You can also send the report to GitLab or GitHub with no agent in the middle. MCP is for teams already working with an agent who want to skip the copy and paste.
Does it work with my framework?
The widget is a plain script tag and depends on no framework. If your page runs in a browser, it runs there.
What language does the widget show to reporters?
The reporter's own, detected from their browser, or a fixed one you choose per project. It does not follow your account language, because reporters can be anywhere.
Start with your first project
Creating the account, grabbing the key and pasting the snippet takes less time than reading this page.
Create free account