Ten years ago, "the website" usually meant one codebase maintained by one team. Today a single company might run its marketing site on Webflow, its docs on a static site generator, its store on Shopify, a product built with an AI app builder, and a few landing pages in Framer for good measure.
That variety is a good thing. It lets the people closest to each page ship changes without waiting on engineering. But it also means feedback tools built for a single app, installed through a package manager and configured in code, don't fit how most sites are actually made anymore.
Here's what we think a feedback tool needs to handle the modern web.
1. Installs anywhere with one snippet
If a tool needs a build step, an npm package, or a framework-specific SDK, it's out of reach for most of the people who manage websites. The baseline should be a single script tag that works anywhere you can add custom code before the closing </body> tag.
That covers a surprising amount of ground: WordPress, Webflow, Framer, Squarespace, Wix, Shopify themes, cPanel-hosted sites, static HTML, and frameworks like Next.js. For hosts that don't allow custom code on some plans, edge platforms such as Cloudflare and Fastly can inject the snippet for you. We keep step-by-step install guides for each of these, because "just add the script" means something different on every builder.
2. Doesn't slow the site down
Performance is a feature, and a feedback widget shouldn't cost you any. A good widget never blocks the page from rendering, and it saves heavier work, like generating a screenshot, for the moment someone actually submits a report. Your visitors shouldn't pay a speed tax for a tool most of them will never click.
3. Works for people who aren't developers
The people who notice problems on a website are mostly not engineers. They're clients reviewing a build, marketers checking a launch, support teams reproducing a complaint, or customers who just want something to work.
So the reporting experience has to be obvious. Click a button, point at the problem, write a sentence, submit. No account required for the reporter, no browser extension to install, and no technical vocabulary.
4. Captures technical context automatically
The flip side of a simple reporting experience is that the technical detail has to come from somewhere. A modern feedback tool should attach the things developers need without asking the reporter for them:
- A screenshot with the reported element marked.
- The page URL and element location.
- Browser, operating system, and screen size.
- Recent console errors and warnings.
- A short session replay of what happened before the report.
This is the difference between a feedback form and a bug report. We wrote more about it in A screenshot is not a bug report.
5. Works on phones
More than half of web traffic is mobile, and plenty of bugs only exist on a small screen. A widget that only works well on desktop will miss exactly the issues that are hardest to spot during development. Reporting on a phone should be as easy as tapping the thing that's wrong.
6. Respects privacy
Session replays and screenshots are powerful, and they need care. A feedback tool should only capture what's needed to understand the report, mask sensitive inputs, and fit cleanly with your site's existing consent setup. If your site uses a cookie banner, the feedback tool should play by the same rules as everything else on the page.
7. Scales across many sites
Agencies and teams with several properties need one place to see everything, organized by site, with the right people on each project. Pricing should be predictable too. We think it's fairest to charge for what you actually get, submitted reports and connected domains, not for every browsing session the widget happens to see.
8. Fits your brand
A feedback button is part of your site's interface. It should match your colors and feel like it belongs there, rather than looking like an ad for someone else's product.
The short version
The modern web is built by more people, with more tools, than ever before. A feedback tool for that web has to install anywhere, stay out of the way, be obvious for non-technical reporters, and still give developers everything they need to fix the problem on the first try.
And once that report exists, it needs to go somewhere useful. That's what we'll cover next week: why feedback should land in the tools your team already uses.