One widget per project: when and why

When teams start collecting embedded bug reports, one of the first structural questions is deceptively simple: should everything funnel through one widget, or should each site and app get its own? Our strong recommendation — and the pattern we see successful teams converge on — is one widget per project. Here is the reasoning, along with the cases where a different split makes sense.

What a widget actually represents

A widget is not just a floating button. It is a configuration bundle: an embed code, a set of enabled features (screenshots, video capture), and a routing destination — which Slack channel gets notified, which Trello board and list receive cards. When you think of a widget as "a pipeline from one audience to one team," the one-per-project rule becomes obvious. Different projects have different audiences and different owners, so they need different pipelines.

Clear ownership ends triage ambiguity

Imagine a report that says "the button on the pricing page is misaligned." If your marketing site and your main application share a widget, someone now has to figure out which pricing page — the public one or the in-app upgrade screen. Multiply that small ambiguity across every report, every day, and triage becomes a guessing game.

With separate widgets, the source is structural rather than inferred. Reports from the marketing site arrive in #marketing-bugs and become cards on the web team's board. Reports from the app arrive in #app-bugs on the product team's board. Nobody asks "whose bug is this?" because the pipeline itself answers the question.

Cleaner data, cleaner decisions

Separation also keeps your signal measurable. When each project has its own stream, you can see at a glance that the dashboard generated forty reports this month while the docs site generated three. That tells you where quality problems actually live and where to invest testing effort. A single merged stream hides this distribution and turns prioritization into anecdote.

There is a subtler benefit too: configuration can match context. On a public marketing site you might keep the form minimal — title and description only — because visitors are anonymous and in a hurry. Inside your app you might enable screenshot capture and video, because logged-in users tolerate a slightly richer form and their bugs tend to be more complex. One widget cannot serve both contexts well; two widgets each serve their context perfectly.

The agency and freelancer case

For agencies and freelancers managing client projects, one widget per client is not just organizational hygiene — it is professional necessity. Each client's reports route to that client's board or channel, which means you can give clients visibility into their own pipeline without exposing anyone else's. When a project ends, you archive one widget without touching the others. Client work stays cleanly partitioned by construction, not by discipline.

When to use more than one widget per project

The one-per-project rule has a useful refinement: split further when audiences or surfaces differ meaningfully. Common patterns include a separate widget for a staging environment (so internal QA reports never mix with production user reports), a separate widget for a beta program (so beta feedback can route to the team running the beta), or separate widgets for web and mobile-web surfaces of the same product when different teams own them.

The test is always the same: would these reports be triaged by different people or through a different process? If yes, use a separate widget. If no, keep them together.

When one widget really is enough

If you run a single product with a single team, do not overthink it. One widget on the app, routed to one channel and one board, is a complete setup. The free tier exists precisely so that this simplest case stays simple. Add widgets when a real second surface appears — a new marketing site, a docs portal, a client project — rather than speculatively.

Scaling up without reorganizing

The pleasant property of the one-per-project pattern is that it scales additively. Adding a project means adding a widget and picking its destinations; nothing about existing pipelines changes. Teams that start disciplined about this rarely need to reorganize later, whereas teams that start with a shared funnel usually end up untangling it during their busiest month. Start separated, and growth stays boring — in the best way.