My fastest Claude Code habit is a support widget

Seven days into moving Premierely from nocode to code with Claude, I had a realization. Most developers describe bugs to Claude Code in text, from memory, after the fact. I let the app describe them automatically. A few clicks through my own product captures the page URL, browser logs, and a screenshot. That package goes straight into Claude Code. It solves faster, asks fewer follow-up questions, and produces fixes that actually match what was broken.

Context quality is the Claude Code tip most people miss – not prompting skill. Here’s the workflow.

Why text descriptions fail Claude Code

When you describe a bug from memory, you’re reconstructing. You remember roughly what happened – maybe you checked the console, noted the URL – but you’re assembling it after you’ve left the context where it happened. Claude Code works with what you give it. Give it a vague reconstruction and it will ask clarifying questions, make assumptions, or solve the wrong version of the problem.

Your output quality is capped by your context quality. And by the time you’ve manually assembled it – dev tools, console errors, screenshot, description – you’ve already broken your own user flow.

What the feedback widget captures in a few clicks

I built a feedback and bug report widget into Premierely, my SaaS for SoundCloud channel owners. The primary use is not for users to report bugs – it’s a development tool I use to stay efficient while testing the product as a user.

When I spot something to fix or build, I click the widget in the bottom left corner. In a few clicks it captures:

• The exact page URL, including route and query parameters
• Browser console logs at that exact moment (errors, warnings, network failures)
• A screenshot of the current page state – you select the region yourself
• A description field where I add what I actually want done

That last point matters. The auto-captured data gives Claude Code the context. The description gives it the intent. Together they replace what would otherwise be three paragraphs of manual reconstruction. The widget bundles everything into a structured report saved to the database – one Claude Code command pulls in the latest one, and the fix usually lands on the first attempt.

Claude Code receives the full picture of what I was looking at – not my remembered version of it. It doesn’t need to ask what page I was on. It doesn’t need to guess what the error said. It has everything in front of it.

Clicking through your own product is the real method

The widget works best when you’re actually using your product.

I run Premierely to manage premieres for Märked, my own label. Every inbound booking request runs through the platform. I click through the same flows my 282 users click through. When something is slow, broken, or confusing, I feel it directly – not through a survey or a support ticket weeks later.

This is what makes it work. The widget is really an on-site development tool disguised as a feedback widget. It’s not passive bug collection – it’s an active testing ritual. You sit down, open your product, walk a user flow as if you’re a customer, and capture what you find along the way.

Writing a bug report from your desk is secondhand. Clicking through the product is not. When you’re inside it, you notice things you’d never think to write down otherwise. The widget makes sure those observations don’t disappear the moment you switch tabs.

Feeding the widget output to Claude Code

The workflow:

1. Open your product and walk through a user flow
2. Spot something that needs fixing or improving
3. Open the feedback widget – take a screenshot, annotate what needs attention, add a short description with direction for the fix
4. Open Claude Code and paste the widget output directly
5. Add one line of intent: “Fix this” or “Here’s what I want to change”

Claude Code receives the page URL, the console state, and a screenshot alongside your instruction.

The difference in response quality is real. Without this context, Claude Code often asks clarifying questions or works from a slightly different understanding of the problem. With it, the fix is usually accurate on the first attempt. You spend less time in the back-and-forth loop that eats up context window space and slows the session down.

AI tools don’t perform better when you prompt harder. They perform better when you give them better input.

It changed what I decided to build

I built the widget expecting one benefit. I got two.

The first: Claude Code gets better context, solves problems faster, asks fewer questions. That one shows up immediately once you try it.

The second surprised me. Clicking through the product regularly changes what I decide to build.

When you test your product by walking through it properly, you find different things than when you sit at a desk making a list of features to add. You notice which flows are slow. You notice where you hesitate. You notice what’s annoying on the fifth time you do it, not just the first. That’s real product signal – the same signal you’d need a QA team to generate if you weren’t doing it yourself.

For a solo founder, that’s the whole game. I run Premierely alone. There’s no QA team, no support team. The widget is how I scale attention without hiring. A 20-minute session of clicking through my own product becomes a structured list of things to fix, with full context attached – ready to hand to Claude Code.

I’m a huge believer in eating your own dogfood, and combining it with an on-site development tool disguised as a feedback widget makes it twice as valuable.

Two outputs from the same 20-minute session – and the second one shapes what you build next.

How I built this for Premierely

Here’s the actual implementation in the Premierely rebuild (Next.js + Supabase).

The widget lives in public/bug-report-widget.js – a self-contained script that can be injected on any page. It starts collecting the moment it loads, passively. No user action needed for the error capture to begin.

What runs automatically from page load:

• Console error interceptor – patches the browser console and stores up to 10 errors with timestamp, message, and stack trace
• Network error interceptor – patches fetch and XMLHttpRequest to catch failed requests, with URL exclusions to prevent the widget itself from triggering recursive captures

What happens when you open the widget and capture:

• The current page URL is read from window.location
• You click the screenshot button, which calls navigator.mediaDevices.getDisplayMedia – this is the native browser Screen Capture API, so the browser prompts for permission and you select the region
• The capture lands on a canvas where you can annotate (pen, rectangle, arrow) before submitting
• You write a description of what you want done

On submit, everything goes to POST /api/qa/report. The server validates the session, stores screenshots in a Supabase storage bucket, and saves the report to a qa_reports table with the full context as structured JSON.

The result is a report with URL, viewport size, user agent, console errors, network errors, annotated screenshots, and your description – all timestamped and linked to your session.

You don’t need all of this. The minimum is URL + console capture + screenshot + a text field. That’s enough to make Claude Code sessions meaningfully faster. The rest is quality-of-life for triaging later.

That’s the Claude Code workflow change that’s had the biggest impact on how fast I ship.