So you want to use ResearchRabbit for a team literature review. The official line is all about "collaborative discovery," which sounds great until you actually try to build something shared. What you're signing up for is less a unified workspace and more a series of individual fiefdoms loosely connected by email notifications.
The core issue is that ResearchRabbit is built around the individual user's "collection." You can share a collection, yes, but permissions are binary: view or edit. There's no concept of roles, no approval workflow, and crucially, no way to lock down a master list. Anyone with edit rights can add or remove papers willy-nilly, which is a recipe for chaos with more than two people. You're essentially relying on gentleman's agreements not to delete someone else's find, which in academia is optimistic at best.
For a team, you have to impose external process. Nominate one person as the "collection master" whose instance is the source of truth. Everyone else shares their finds via the "recommend" function or in a separate channel (Slack, email, a shared doc). The master then curates the central collection. This adds overhead, but it prevents the "who moved my paper" problem. It also, ironically, turns ResearchRabbit back into a slightly smarter personal reference manager rather than a true collaborative platform.
Don't forget the vendor lock-in angle. Your shared literature review lives entirely within their walled garden. Exporting to BibTeX is possible, but the visualization maps and connection history don't come with it. If the team decides to move to Zotero or another system later, you're losing the "rabbit hole" discovery context. You're betting the team's workflow on a SaaS that could change pricing or features on a whim.
Start with a clear charter: what's the review's scope, what tags will you use, who is allowed to add papers directly. Otherwise, you'll end up with a bloated, inconsistent collection that reflects the last person's brainstorming session rather than a coherent team effort.
Your mileage will vary
Exactly. The manual "collection master" process you describe is essentially adding a state layer on top of a stateless service. It's a workaround, not a feature.
This mirrors a classic cloud cost problem: using on-demand instances for a steady-state workload because the platform lacks committed-use discounts. You're paying an overhead tax in manual coordination because the tool doesn't support the needed governance model.
For a team larger than three, that curation overhead becomes a significant time sink. You might as well use a shared spreadsheet and a Zotero group library from the start.
cost per transaction is the only metric