SaaS Research Repository: Build vs Buy (Dovetail, EnjoyHQ)
When SaaS teams should build a custom research repository vs. buy tools like Dovetail or EnjoyHQ — decision criteria, cost models, and the maturity threshold for each approach.
Most SaaS teams accumulate customer research the same way they accumulate technical debt — gradually, then suddenly. A folder of interview recordings here, a Notion page of survey results there, a Slack thread where someone summarized six months of support tickets. By the time the team realizes they need a research repository, they already have one — it just doesn't work. The decision to build a proper system or buy a dedicated tool turns on a few specific variables: research volume, team size, and how findable past insights need to be to people who weren't in the room.
What a Research Repository Is — and Why It Matters
A research repository is a centralized, searchable system for storing, tagging, and retrieving customer research artifacts. This includes interview recordings and transcripts, survey results, usability test notes, NPS responses, support tickets tagged to product themes, win-loss interview summaries, and synthesized insight documents.
The goal is not storage. Storage is solved by any file system or Notion workspace. The goal is retrieval — the ability for a product manager who wasn't present for a study six months ago to find the relevant insight in under three minutes when they need it.
Without structured retrieval, research accumulates without compounding. Teams re-interview the same customer segments. Product decisions get made without surfacing relevant past evidence. New team members can't access institutional knowledge. The research happened, but it doesn't inform — because no one can find it.
This distinction matters for the build vs. buy decision. A research repository that solves the storage problem but not the retrieval problem is a false solution. Any evaluation of tools or DIY approaches should start with retrieval as the primary requirement.
Research repositories connect directly to the broader voice of customer program a team runs. A VoC program without a repository is like a library without a catalog — the books exist, but the knowledge doesn't circulate.
The Build Option: Notion, Airtable, and Custom Systems
The build path typically starts with Notion — a database of research studies, linked to individual participant pages, with tags for product area, insight type, and customer segment. Some teams use Airtable for its more structured database behavior. A small number of engineering-heavy teams build internal tools on top of their data warehouse.
When a DIY Repository Works
The build path works well under a specific set of conditions:
Research volume is low. Fewer than 5-6 sessions per month means the repository grows slowly enough that manual curation is tractable. A team running 3 customer interviews per month can maintain a Notion workspace with consistent quality because there's time to tag properly after each session.
The team is small. With one or two people managing the repository, taxonomy drift is a solvable social problem — you can enforce consistency through conversation. At four or more contributors, consistency requires either tooling enforcement or significant process overhead.
Research types are homogeneous. If your team does almost exclusively semi-structured interviews, a single Notion database with a consistent template handles the job. Mixed-signal environments — interviews plus NPS plus support tickets plus product analytics — strain DIY systems quickly.
Speed to value matters more than long-term scale. A well-structured Notion database can be live in two days. Onboarding Dovetail, establishing taxonomy, and training the team takes two to four weeks. For an early-stage team that needs to move fast, the DIY path gets knowledge moving sooner.
The Limitations That Accumulate
The core problem with DIY repositories isn't the initial setup — it's the maintenance trajectory. Three failure modes emerge predictably:
Taxonomy drift. Over time, each team member adds tags that make sense to them but don't map to existing vocabulary. "pricing" and "price sensitivity" and "cost objection" are three tags for the same concept. The more tags proliferate, the less useful search becomes.
Findability decay. Notion's full-text search works reasonably well at low volume. Past 200-300 documents, search quality degrades relative to purpose-built tools because Notion isn't optimized for the retrieval patterns researchers use — searching by insight type across participant segments, filtering by product area and date range simultaneously, surfacing related studies.
Maintenance abandonment. DIY repositories require active curation. When team priorities shift, curation stops. Within two quarters, the repository's value drops sharply because new additions are inconsistently tagged and old entries become stale without any mechanism to surface or update them.
The churn interview protocol is a good stress test for any repository: can a new team member find all past churn interview insights for a specific customer segment, filtered to the last 12 months, in under five minutes? If the answer is no, the build path has already hit its limits.
The Buy Option: Dovetail, EnjoyHQ, and Aurelius
The purpose-built research repository market has matured significantly. The three dominant players — Dovetail, EnjoyHQ, and Aurelius — each make distinct architectural choices that make them suited to different contexts.
Dovetail
Dovetail is built around the synthesis workflow. The core interaction is tagging — highlighting sections of transcripts or notes and applying tags that become queryable across all studies. Dovetail then clusters tagged content into "insights" and maintains evidence trails that link insights back to the raw data.
This architecture suits teams doing primarily moderated research: interviews, usability tests, diary studies. The transcript-centric tagging model creates a structured evidence layer on top of raw data that makes qualitative insights auditable and shareable.
Dovetail's pricing sits at roughly $29-39 per user per month for its standard tier (pricing changes periodically; verify current pricing at dovetailapp.com). For a three-person research team, that's $87-117/month — a low threshold if the team is doing serious synthesis work. The cost scales with seats and storage, which matters for larger organizations with many stakeholders who need read access.
Where Dovetail struggles: high-volume feedback aggregation. Pulling NPS responses, support tickets, and in-app feedback into Dovetail and making them searchable alongside interview data is possible but not the platform's strength. Teams with a complex mixed-signal environment often find Dovetail's import workflows cumbersome at scale.
EnjoyHQ
EnjoyHQ (acquired by UserTesting) is built around aggregation. Its core capability is pulling feedback from multiple sources — Zendesk, Intercom, Salesforce, Typeform, NPS tools, app store reviews — into a single searchable repository. The search layer is more sophisticated than most DIY alternatives, with smart grouping and sentiment analysis.
EnjoyHQ suits teams managing high-volume, mixed-signal feedback where the bottleneck is finding relevant feedback across sources rather than synthesizing a single study. A customer success team that needs to surface all customer feedback on a specific feature, across support tickets, NPS verbatims, and interview notes, finds EnjoyHQ's aggregation model more natural than Dovetail's study-centric approach.
Pricing sits in the $200-500/month range for small teams (check enjoyhq.com for current pricing). This higher floor makes EnjoyHQ harder to justify for early-stage teams; the ROI threshold requires meaningful research volume and at least partial involvement from CS, product, and sales in surfacing feedback.
Aurelius
Aurelius targets the same synthesis-focused workflow as Dovetail but with a simpler interface that some smaller teams find easier to adopt. It's worth evaluating if Dovetail feels over-engineered for a team's workflow. Pricing is comparable.
Decision Framework: Maturity Level, Team Size, Research Volume
The choice between build and buy follows a reasonably predictable maturity curve. The research frequency patterns by company stage provide the baseline context for where your team sits.
| Stage | Monthly Research Sessions | Team Size | Recommendation |
|---|---|---|---|
| Pre-PMF | 1-4 | 1-2 researchers | DIY (Notion) |
| Early Growth | 5-10 | 2-3 researchers | DIY with enforced taxonomy, or Dovetail starter |
| Growth | 10-20 | 3-5 researchers | Dovetail (synthesis-heavy) or EnjoyHQ (mixed-signal) |
| Scale | 20+ | 5+ researchers | EnjoyHQ or Dovetail + dedicated research ops |
Beyond volume and headcount, two qualitative factors tip the decision:
Stakeholder breadth. If research needs to be discoverable by people outside the core research team — product managers, executives, sales, customer success — a DIY system breaks down faster because these stakeholders aren't willing to maintain research hygiene. Paid tools provide a read-only access model that keeps the repository useful without requiring external contributors to learn the system.
Decision frequency. High-velocity product teams making weekly prioritization decisions need research to be retrievable on short notice. If the team is running win-loss analysis and needs to cross-reference patterns from past deal interviews, the retrieval speed of a purpose-built tool justifies its cost even at modest research volume.
Cost Comparison Model
A rigorous build vs. buy comparison accounts for three cost categories: tool cost, setup and onboarding cost, and ongoing maintenance cost.
Tool cost is the easiest to calculate. A Notion Plus workspace is ~$16/month per user. Dovetail at ~$35/month per user with four users is $140/month. EnjoyHQ's small-team plan runs ~$250-300/month. At scale (10+ users), the DIY tool cost advantage erodes as Notion's per-seat pricing converges with Dovetail's.
Setup and onboarding cost favors DIY in the short term. Standing up a Notion research database takes a few days of one person's time. Onboarding Dovetail, establishing taxonomy, training the team on tagging conventions, and migrating existing research takes two to four weeks — at a researcher's fully loaded cost of $100-200/hour, that's $8,000-32,000 in labor for the transition.
Ongoing maintenance cost is where the calculation inverts. DIY systems require 2-4 hours of active curation per week to maintain retrieval quality. At scale, that's a partial headcount allocation. Purpose-built tools offload curation through enforced structure, better search, and automated reminders — reducing maintenance overhead to 30-60 minutes per week.
The crossover point for most teams is 10-15 monthly research sessions with three or more regular contributors. Below that threshold, DIY total cost of ownership is lower. Above it, the maintenance savings and retrieval quality improvements of a paid tool typically offset the subscription cost within one quarter.
A frequently overlooked ROI factor: duplicate research elimination. When teams can't find past research, they commission new research to answer questions that have already been answered. Nielsen Norman Group's research on enterprise UX maturity indicates that organizations with structured research repositories reduce duplicated studies by 20-30% annually. At an average study cost of $3,000-8,000 (researcher time plus participant incentives), a team running 24 studies per year saves $15,000-40,000 in avoided duplication alone.
Migration Considerations: From DIY to Paid Tools
Teams that have been running a DIY repository for a year or more face a real migration challenge when moving to a paid tool. The temptation is to migrate everything — all historical research, every document, every old tag. This almost always fails.
A more practical migration approach:
Audit before migrating. Spend a week tagging which historical research is still relevant vs. which is out-of-date or low-quality. Research more than 18-24 months old is rarely retrieved in practice unless the team is studying long-term trends. Limit the migration scope to the last 12-18 months.
Establish the new taxonomy first. Design the tag vocabulary in the paid tool before importing a single document. Migrating historical data and then retrofitting taxonomy onto it recreates the same drift problem that made the DIY system fail. The taxonomy design session — ideally a half-day workshop with all research contributors — is the highest-leverage activity in the migration.
Migrate by project, not by date. Import complete research projects (all artifacts from a given study together) rather than doing date-based batch imports. This preserves the relationships between artifacts that make synthesis possible.
Budget migration time realistically. A team with one year of DIY research should budget two to three weeks of migration effort spread over four to six weeks. Two to three years of history requires four to six weeks of effort with a dedicated owner.
Don't migrate everything immediately. Make the new system the home for all new research from day one. Historical migration can happen in parallel over 60-90 days. The sunk cost of incomplete historical migration is low; the cost of delay in adopting a better system is higher.
Making Research Findable Across the Organization
The most underrated challenge in research repository design isn't technology — it's making research visible and retrievable to people who don't know they need it.
A product manager doesn't search the repository because they don't know which past research is relevant to their current decision. A sales rep doesn't check for customer feedback on a feature because checking the repository isn't part of their workflow.
Three mechanisms make research more permeable:
Regular research digests. A monthly or bi-weekly email (or Slack digest) summarizing new insights added to the repository keeps research top-of-mind for stakeholders who don't check the system proactively. This is a low-effort, high-reach practice that compounds over time.
Research-to-ticket linking. When product decisions are informed by specific research, link the repository entry to the JIRA ticket or product spec. This creates a discovery path in the other direction — someone reviewing an old ticket finds the research that motivated it.
Insight briefs for major decisions. Before quarterly planning or major feature prioritization, a researcher pulls a brief from the repository: "Here's everything we know about [topic] from the last 12 months." This proactive surfacing of existing knowledge prevents the "we don't have data on this" assumption that drives unnecessary new research.
The repository is infrastructure. Like any infrastructure, its value is realized through usage patterns, not just existence. Teams that invest in the social and workflow layer — how research flows into decisions — get more return from their repository than teams that invest only in the tool layer.
See Your Growth Ceiling Now
Calculate when your SaaS growth will plateau — free, no signup required.
Frequently Asked Questions
What is a research repository in SaaS?
A research repository is a centralized, searchable database of all customer research artifacts — interview recordings, transcripts, survey responses, usability test notes, support tickets, and synthesized insights. It makes past research discoverable across the organization so teams stop re-asking questions that have already been answered.
When should a SaaS team start using a dedicated research repository tool?
When your team produces more than 5-6 research sessions per month, or when more than two people regularly need to access or reference past research. Below that volume, a well-structured Notion or Airtable setup is often sufficient. Above it, the search and tagging limitations of DIY tools create more friction than a paid tool's onboarding cost.
Is Dovetail worth the cost for early-stage SaaS startups?
For most early-stage teams (pre-Series A, fewer than 3 researchers), Dovetail is likely over-engineered and over-priced. The platform's value compounds with research volume and team size. A Notion-based repository with a consistent tagging taxonomy often serves teams better until they hit the 10+ monthly research sessions threshold.
What is the difference between Dovetail and EnjoyHQ?
Dovetail is built around synthesis — tagging transcripts, clustering insights, and building evidence trails. EnjoyHQ (now part of UserTesting) is built around aggregation — pulling feedback from Intercom, Zendesk, surveys, NPS, and interviews into one searchable place. Teams primarily doing moderated research tend to prefer Dovetail; teams managing high-volume mixed-signal feedback lean toward EnjoyHQ.
How do you build a research repository in Notion?
Create a database with consistent properties: research type, date, participant segment, product area, and key insights. Link each study to a parent 'research question' page. Use a controlled tag vocabulary (limit to 30-50 tags maximum) and enforce it with a team norm. Add a monthly 'synthesis session' to resurface aging insights before they become stale.
What are the main risks of building a custom research repository?
Three main risks: (1) taxonomy drift — tags become inconsistent as team members add their own without coordination; (2) findability decay — search works well at first but degrades as volume grows and metadata quality drops; (3) maintenance burden — someone must curate the system or it accumulates debt. Paid tools address all three with enforced structure and better search.
How should teams migrate from a DIY repository to Dovetail or EnjoyHQ?
Prioritize recency over completeness. Migrate the last 12 months of research first, using the paid tool's import templates where possible. Establish the new taxonomy before migrating historical data — retrofitting an old taxonomy onto a new tool recreates the same problems. Treat the migration as a 4-6 week project with a dedicated owner.
Does having a research repository actually reduce research costs?
Yes, measurably. Nielsen Norman Group research shows that organizations with structured research repositories reduce duplicate research by 20-30% annually. At an average cost of $3,000-8,000 per research study (researcher time plus participant incentives), a team running 24 studies per year could save $15,000-40,000 per year in avoided duplication alone.
Conclusion: The Threshold Matters More Than the Tool
The build vs. buy decision for a research repository is less about tool features and more about organizational maturity and research volume. Below the threshold — roughly 5-6 sessions per month with one or two contributors — the overhead of a paid tool exceeds its benefits. Above it, the maintenance costs and retrieval limitations of DIY systems compound faster than most teams expect.
The specific tool matters less than the discipline that surrounds it. A well-maintained Notion database outperforms a poorly governed Dovetail instance. The taxonomy, the curation habits, the workflows that route insights to decisions — these determine whether a research repository becomes a strategic asset or an expensive folder.
Teams that build before they need it waste money and attention. Teams that wait too long accumulate a backlog of unfindable research and a migration project that becomes the organizational equivalent of paying off high-interest debt. The decision criteria outlined here — volume threshold, team size, stakeholder breadth, decision frequency — are the most reliable signals for timing the transition.
Start with the simplest system that preserves retrieval quality. Upgrade when the signals are clear. Invest in the social layer regardless of which tool you use.