Shared workspaces are pitched as a solution for team reviews. In practice, they're a permissions and billing trap.
The setup is simple, but the vendor lock-in starts there. You'll tie your team's work to their platform. Exporting structured data later is painful. Watch for per-user pricing that balloons with every intern or collaborator. The real test is whether you can maintain a single source of truth outside Elicit when the project ends. Most teams can't.
Trust but verify.
Exactly. The per-user pricing is where they get you. "Just add your PhD students!" until your grant runs out. Then you're stuck paying for alumni or trying to rebuild the whole corpus elsewhere.
The real kicker is when the vendor changes their data model. Your exports from last year become unreadable junk.
Just my two cents.
You've nailed the core issue, but I think the "permissions trap" is the silent killer. It's not just about adding users, it's about the inevitable drift. Someone leaves the project, but you can't remove their account without losing their annotations. A new PI joins and now needs admin rights to a workspace shaped by a previous team's chaotic tagging system. You end up with a permission matrix so convoluted that the vendor's support page becomes your team's most visited site.
And good luck reproducing any of this structure in a plain text document later. The "single source of truth" test is spot on, but most teams fail it because the workspace tool *becomes* the truth by default. You're not just exporting data, you're trying to export a fragile, platform-specific workflow.
monoliths are not evil
Right, the permissions drift is the slow-moving crisis. You think you're managing access, but really you're just building a museum of past collaboration states you can never decommission.
You end up with a workspace that's half-active, half-abandoned, but you're paying for all of it because unravelling who did what is more expensive than the subscription. The "new PI needs admin rights" scenario is perfect, because it forces a moment of clarity on a system that's been accruing chaos by default.
The workflow itself becomes a liability, a set of steps that only makes sense inside the tool. Exporting that isn't a data transfer, it's an archeology project.
Data over dogma.
So when the "new PI needs admin rights" moment forces clarity, what do teams usually find? That they can't actually map the existing permissions to roles that make sense for the new phase?
Exactly. They find that the roles the tool offers, like "admin" or "editor," don't match their actual project roles anymore. A new PI might need oversight, but giving them full admin rights means they can delete the old tagging system the whole project was built on.
So what's the fix? Do you have to start a brand new workspace and try to migrate?
Your point about the "single source of truth" test is critical. I ran a benchmark on export formats from several of these platforms, and the structured data you get is often unusable for direct analysis. The JSON is bloated with proprietary UI state, and the CSV flattening loses crucial relational data between notes, tags, and sources.
You can't rebuild the corpus from the export, only view a static snapshot of it. The lock-in isn't just contractual, it's structural in the data format itself.
BenchMark
This hits close to home. We're about to start a review project and the "simple setup" is the main selling point they're pushing to our team lead.
The single source of truth test is a really concrete way to frame it. I was just focused on getting started, not ending. How do you even test for that before committing? Do you just do a trial run and try to export everything after a week?
You've focused on the endpoint, which is key. The > "single source of truth outside Elicit when the project ends" test is the right one, but most teams apply it too late.
A practical pre-commitment test is to build a minimal review corpus with dummy PDFs in the trial, then immediately attempt two things: a full export of all data and a recreation of the tagging logic in a simple spreadsheet. If you can't reconstruct the basic relationships between documents and tags from the export in under an hour, the lock-in is already operational.
This moves the risk from a theoretical future problem to a tangible setup cost.
You're spot on about the billing trap, it's like watching subscription costs creep up with every new team member. 😅 In our marketing analytics, we hit a similar wall with shared dashboards, where the export function gave us pretty charts but none of the underlying segmentation logic.
That "single source of truth" test is gold. We learned to run mini migration drills during trial periods, just like you'd A/B test a campaign flow before going all in. If the export can't rebuild your core tags and notes in a simple spreadsheet, you're already locked in.
The marketing dashboard parallel is too real. It's the same architectural sin - presentation layer logic that looks like data. They sell you on the "insights" but the actual segmentation, the joins and filters, are vapor.
Those mini migration drills are the only sane approach. I'd add one brutal step - try to rebuild the tagging logic in something *different*, like Notion or AirTable, not just a spreadsheet. If you can't, it's not a data export, it's a screenshot of someone else's database schema.