From Basics to Best Practices: Introduction to Research Repositories
Learn more about the underlying concepts, potential, and strategic approaches to selecting the ideal research repository for your organization
Build vs. Buy a Research Repository: The Costs Nobody Tells You About
TL;DR: “Just build it with AI” sounds like a great way to save on license costs. But whether you build a research repository yourself or buy a dedicated tool, there are always costs involved, whether money, time, manpower, or even peace of mind. Understanding the full costs upfront will help you choose the right approach for your team.
Kaleb Loosbrock, Founder of the AIxUXR community and independent UXR & AI consultant, knows this firsthand. During his four and a half years at his previous company, he and his team went through four different attempts at building an in-house research repository. By the time he left, a fifth was already on the table.
In a recent Condens Meetup, Kaleb sat down with Alexander Knoll, CEO and Co-Founder of Condens, to unpack what teams should consider before deciding whether to build or buy. This article brings together the key lessons from their conversation and takes a closer look at what a research repository really costs.
Building an In-House Research Repository: Lessons from Four Attempts
At Kaleb’s previous company, they tried four different approaches to building their in-house research repository, and none of them really stuck. “Every single year we attempted a different [approach],” Kaleb said in the webinar. Here’s how it played out.
A knowledge-management platform: This one was just rolling out when Kaleb joined. The interface was “ugly” and “convoluted,” and the taxonomy was so complicated that people simply stopped following it. Kaleb described asking partners to log in and use it as “an adoption buzzkill.”
A homegrown AI layer on top: About six months later, the team hooked its own AI tool up to the platform through its API. Queries spiked at launch, and people loved it. But after about three months, quality started slipping. New models came out, and they didn’t manage to stay on top of running the regression tests necessary to maintain the system.
A company-wide platform's AI assistant: Next, they rolled out a company-wide knowledge platform with a built-in AI assistant. According to Kaleb, it was “okay, but it didn’t match what we wanted.”
A repository next to the enterprise tool: So the team added a repository built for UX research analysis and reports. The catch? They still had to use the company-wide platform, too. Juggling two systems split the workflow, and eventually the whole setup collapsed.
And then there was plan number five. Just as Kaleb was heading out the door, the idea on the table was to drop every vendor and “just build it ourselves with AI.” That’s when, as he put it, he “waved the white flag.”
“None of it really worked. And it wasn’t the tools’ fault,” Kaleb shared. Ultimately, every attempt tripped over the same things: usability, upkeep, scope, and adoption.
Whether You Build or Buy, You’re Going to Pay
Build vs. buy is really the wrong question because you pay either way. If you buy, you pay a partner. If you build with AI, you pay for the engineer, or more likely the researcher or ResearchOps person who becomes responsible for keeping the system running. The costs to build are less straightforward than the price paid to a partner platform, which is why building tends to look cheaper than it really is. But as Kaleb summed up: “There is no free research repository. There never was.”
He didn’t sugarcoat his words in the webinar, either. Most research teams can’t turn into software engineers overnight, let alone AI engineers who can build a customized research repository. If you’ve got people who can dedicate their time to setting up and maintaining the system, great. If you don’t, “you’re probably not even aware of just how much you would pay.”
Before you decide on which direction to take, dig into the underlying questions that need to be answered first:
What problem are you solving?
Who are you building for?
What does success look like?
As Kaleb said, “get those clear, and the build-versus-buy decision mostly answers itself.”
Three Ways to Set Up a Research Repository
There are generally three ways to set up a research repository: build it from scratch, take a hybrid approach using a general-purpose tool with an AI layer on top, or buy a dedicated research repository.
Approach | How it works | Best fit for | What to consider |
|---|---|---|---|
Build from scratch | You develop and customize your own research repository from the ground up. | No vendor meets your requirements, and you have the engineering resources to build and maintain an in-house solution long-term. | Ongoing engineering and maintenance, AI usage costs, and keeping security and compliance requirements up to date. |
Build on a general-purpose tool | You organize research in an existing workspace, like Notion, Confluence, or SharePoint, and use its built-in AI capabilities or layer a separate LLM on top. | Your research setup is relatively simple and you want to get started quickly using tools already available to your team. | Limitations can emerge as research scales, particularly around data volume, search, anonymization, permissions, usage analytics, maintenance, and compliance. |
Buy a dedicated repository | You use a purpose-built research repository such as Condens, with research workflows, AI, governance, and stakeholder access built in. | Your research data and stakeholder needs are growing, and you need advanced permissions, security, governance, anonymization, and easier ways to share insights. | License costs and the adoption effort required to successfully establish any shared research system. |
Based on Alex’s observations, building from scratch rarely pays off. A hybrid approach, however, can be a great place to start, especially for smaller teams without a complex research setup. The trade-off is that research analysis and the repository often live in separate places, making it harder to connect raw data, analysis, and insights.
And as research scales, access permissions, data security, and anonymization can become increasingly difficult to manage. That’s often the point when teams move to a dedicated research repository that brings the full research workflow together.
What Does It Really Cost to Build a Research Repository with AI?
AI is great at giving you a first version that works well on a sample set. But once you move past that and on to real data with real people, a whole set of bigger problems tends to open up.
Messy data: AI needs well-structured, labeled data, and most research archives aren’t. Reports often get saved in all sorts of ways, and people tend to forget to upload new ones.
Model updates: Every new model can disrupt your repository. Without regression testing, quality can slowly start to slip.
Query costs: Every question asked burns tokens, and the more people use the tool, the bigger the bill.
Consent and compliance: Regulations like GDPR and the EU AI Act may require participants’ consent before their data is processed by AI. It’s worth checking with your legal team how this applies to your research.
Permissions and security: The idea that you can put everything on Google Drive and just connect it to AI can make it difficult to lock down sensitive material.
Search quality: Searching through research isn’t like a Google search. Context and other relevant content are important instead of just one top result.
Traceability: A repository is most useful when insights stay connected to and traceable back to the research behind them. If analysis happens in a separate tool, you need to build and maintain that traceability yourself, from raw data and highlights to findings and final insights.
Hitting the Scalability Wall
In his article, “Buy vs build with AI? Either way you’re going to pay”, Kaleb recounts the story of a healthcare company that built its own AI assistant because no vendor could meet its compliance requirements. Adoption took off at first, then reality set in: “two full-time engineers on reliability alone, twice-weekly outages,” plus a rebuild-or-wait decision every time a vendor shipped a new feature. In Kaleb’s summary, the company’s leadership eventually had to reckon with the costs of becoming their own AI vendor.
The Cost to the Person in the Loop
There’s a human cost that should be taken into account as well. Kaleb points to Lisanne Bainbridge’s 1983 paper on the ironies of automation: automate the easy parts, and the job left for the human gets harder, because now they’re supervising a system whose failures aren’t always obvious. More recent research from BCG, published in Harvard Business Review, also links intense AI oversight to a kind of mental exhaustion the authors call “AI brain fry”.
Kaleb knows that feeling firsthand. “We talk about human-in-the-loop, but I was the only person catching everything,” he said, referencing his experience building with AI.
Time and Opportunity Costs
The amount of time and manpower that goes into building and maintaining a research repository is the cost teams most often overlook. One research leader Kaleb previously spoke to had four researchers, each spending 25% of their time maintaining an insights engine.
There’s a personal cost as well to the researchers. Every hour spent building and maintaining a repository is an hour not spent on actual research. As Alex asked in the webinar: “Is building the repository itself the most impactful thing you can do?”
When Is Notion or Confluence Enough for a Research Repository?
Notion or Confluence is often sufficient when you’re just getting started. In fact, Alex says most teams who come to Condens began their repository in a tool like these. It’s a completely valid path that allows you to skip vendor onboarding and get going right away.
Kaleb agrees, and he says scale is the best way to tell whether it’s still enough. A small startup can often get by with a homegrown setup or a tool overlaid with AI. To figure out where you stand, ask yourself:
How much research data do you have?
How big is your team?
How far back does your data go?
How often does it get refreshed?
In Alex’s experience, teams tend to hit a tipping point after a year or two. Here are the signs to watch for:
It’s getting hard to keep up with maintenance: As your research grows and time goes by, keeping the repository organized and in good working order takes more and more effort.
Data protection gets tricky: It gets harder to keep track of which data has been anonymized, what needs to be deleted, and when.
You want to know who’s using it: Usage analytics, like which teams use the repository and what they ask, typically aren’t available in general-purpose tools.
How Much Does a Research Repository Cost? Build vs. Buy Compared
Buying a dedicated research repository comes with a clear subscription cost. With Condens, plans start at €15 per month for individuals and €500 per month for teams on the Business plan. Building your own doesn’t make that cost disappear. It simply shifts the costs to engineering time, AI usage, maintenance, and other ongoing work.
Cost | Buy a dedicated repository | Build your own with AI |
|---|---|---|
Software licenses | Predictable subscription cost based on your plan | Licenses for general-purpose tools, infrastructure, and AI services |
Engineering and maintenance | Included | Engineering time to build, test, maintain, and update the system |
AI usage | Included | Ongoing model and token costs that grow with usage |
Design, support, and onboarding help | Included | Your team needs to take on these responsibilities |
Security and compliance | Security, compliance features, and product updates are built into the solution | Your team needs to build, maintain, and regularly review them |
Kaleb points out that hiring two AI engineers (like the healthcare company referenced earlier) can cost several times more than a dedicated solution. Alex adds that a single US-based engineer's salary can already exceed the average budget for an enterprise-grade platform. And that's without accounting for design, support, customer success, and ongoing infrastructure costs.
To put it in perspective, Condens spends millions a year on building, maintaining, and delivering its product. That’s the work you’re signing up for when you build your own repository.
What Makes a Research Repository Succeed?
Whichever path you choose, the same three things decide whether people actually use a repository or not: clear goals, real ownership, and steady adoption work. Here are seven practices that can help make a difference.
1. Define Success Before You Pick a Tool
Kaleb always starts with the same questions:
What are your goals and objectives for this project?
What are you trying to achieve?
What does success look like?
Think about who you’re building for, where they find insights today, and how they check whether those insights are still current. If your goal is getting research into VP-level strategy documents, for example, you might need AI that surfaces findings wherever leaders go looking.
2. Measure Value, Not Logins
“Be very careful with your success metrics,” Kaleb warns. Getting 100 people to log in is a very different goal from answering 100 questions.
Instead, consider looking at things like questions asked, questions successfully answered, or stakeholder satisfaction with research results.
3. Give Your Repository a Dedicated Owner
Lack of ownership is the most common reason that repositories fall apart. According to Alex, having a champion is “the number one thing” that leads to successfully setting up a research repository.
At larger corporations, it may be necessary for the repository to have a dedicated owner supported by a researcher who understands the craft. For small and mid-size companies, part-time ownership can work well, depending on their goals and scope.
4. Keep It Structured
Kaleb calls maintenance the first of “the two silent repo killers.” A repository only stays useful if its structure holds: files in the right place, consistent metadata and formatting, and a shared vocabulary everyone knows. Without consistent upkeep, the repository slowly drifts into disorder.
5. Meet Stakeholders Where They’re At
The second silent killer is adoption. According to Kaleb, “most repositories are built for the researcher”. And the product manager in the middle of a product review is unlikely to log in.
Alex’s rule of thumb for making research accessible is to go where your stakeholders already are. If they live in Slack, integrate your repository with Slack so they can directly access research findings from there. If they work in AI tools, connect your repository through an MCP server.
6. Plan for Change Management
Adoption almost always takes longer than expected, and one launch announcement won’t cut it.
Alex shared an example of a Condens customer who’s one of Europe’s largest furniture retailers. Their goal was to get 100 monthly active users in their repository after three months of setting up the repository. Realistically, it took about a year of sharing research findings through key channels (newsletters, Slack channels, etc.) before the team felt familiar enough with having a research repository to actively make use of it. Once they got there, though, adoption stuck.
NN/g’s data backs this up. Among repositories older than three years, 65% reported good adoption, compared with just 34% of those under a year old.
7. Bring IT In Early
Don’t leave security compliance for last. Overlooking permissions and data protection can sink a repository. And if IT isn’t on board, Kaleb warns, “they will sabotage that faster than anybody.” So make sure to review security, data protection, and AI processing early in your selection process.
The Bottom Line
After four attempts at building an in-house repository, Kaleb came away with one conclusion: “Either way and either solution, you’re going to pay.”
The question isn’t whether building is cheaper than buying. It’s where you want your team to spend its time and money.
For a small team with relatively simple research needs, a general-purpose tool with AI layered on top may be all you need. As research scales, so do the demands around maintenance, permissions, anonymization, search quality, compliance, and stakeholder access. And building from scratch means taking responsibility for all of them.
So before you build, ask yourself one more question: Do you actually want to own a research repository or do you want to own the job of building and maintaining one?
FAQs
If you have any questions, feel free to reach out to us at hello@condens.io.
-
A research repository is a central place where teams store, analyze, organize, and share user research data and insights. It can contain interview recordings, transcripts, notes, highlights, findings, and research reports. A UX research repository makes past research easier to find and reuse, helping teams avoid duplicate studies and make decisions based on existing user evidence.
-
Whether you should build or buy a research repository depends on your requirements, resources, and the scale of your research. Building your own gives you more control but requires ongoing engineering, maintenance, security, and AI costs. Many teams start with a general-purpose tool and move to a dedicated research repository as they need better analysis, search, permissions, anonymization, data governance, and stakeholder access.
-
Yes, you can build an AI-powered research repository, and creating a working prototype can be relatively quick. The bigger challenge is maintaining it over time. Teams need to account for model updates, AI usage costs, search quality, permissions, anonymization, data security, compliance, and the ongoing engineering needed to keep the repository reliable.
-
Notion or Confluence can work as a research repository for smaller teams with relatively simple research needs. As the amount of research data and number of users grow, these setups can become harder to manage. Teams may need a dedicated UX research repository when they require more advanced research analysis, search, anonymization, permissions, data governance, and ways to share insights with stakeholders.
-
A research repository should have a clear owner responsible for maintaining its structure, keeping research up to date, and driving adoption. This is often a ResearchOps professional, UX researcher, or someone who works closely with the research team. In larger organizations, a dedicated repository owner can be more effective than spreading responsibility across several people.
About the Author
Phillis Haňo
Phillis is a Content Marketing Strategist at Condens. As a content creator, she produces both long and short-form content in various formats, from blog articles and social media posts to video snippets. She is passionate about ensuring that her work is high-quality and strives to publish content that is both informative and actionable for the UX research community.