01
Data readiness report
PilotFor the pilot sources
ProductionUpdated for every added source
How you verify itYour data owners confirm that the source list, known gaps and access rules match reality
Custom RAG Development Services
Sourced answers from your own documents and databases
Merehead builds retrieval-augmented generation systems for your employees and customers: internal knowledge search, customer support assistants and AI features inside an existing product.
Most engagements start with a scoped pilot or a review of a system you already have. Answer quality is tested on your real questions before anything goes to production.
Services
What Our Custom RAG Development Services Include
You can hire us for a single stage, such as checking whether your data is ready for RAG at all, or for the full build through launch and support.
- 1
RAG consulting and data readiness assessment
When you need itYou have a use case, but you don't know whether your documents, formats and permissions will support reliable answers, or what a pilot should cover. - 2
RAG pipeline development
When you need itYou need a retrieval layer built over your sources and kept in sync with them. - 3
LLM application and integration
When you need itAnswers have to show up where people already work: a chat interface, your product, a helpdesk, Slack or a CRM. - 4
Quality evaluation and optimization
When you need itA prototype exists, but nobody can say how often it is right, or it keeps failing on certain questions. - 5
Deployment and ongoing support
When you need itThe system has to run in your environment, under your security rules, and keep up with data that changes every week.
Common Use Cases
An internal knowledge assistant over wikis, policies and project documentation
Customer support answers drawn from help center articles, resolved tickets and product docs, often delivered through an AI chatbot
Document Q&A for legal, compliance and procurement teams who work with contracts and regulations
Sales enablement: product specs, pricing rules and reference material on request
Search across technical documentation and engineering runbooks
Our support staff used to look for answers in instructions or ask senior colleagues. Now the RAG assistant handles most of these questions. It helps that you can open the source document right away and check the answer. After the pilot, the team itself asked to add materials from our other products.
Case study
Case: RAG Assistant for an Insurance Company
An insurance company needed its staff to find answers in a large, scattered document base: policy terms, internal instructions and claims settlement procedures. Not every department was allowed to see every document.
Merehead built a RAG assistant over 12,000 of these documents. The work covered:
- Ingestion of all three document types into a single searchable index
- Hybrid search that combines keyword and semantic matching
- A relevance check on retrieved passages before an answer is generated
- Department-level access, so employees only get answers from documents their department may see
- Answers with links to the source documents, and an explicit message when the sources don't contain enough information
12,000documents indexed
4people on the team
10 weeksto deliver
Stack
PythonFastAPILangChainPostgreSQL + pgvectorOpenAI APIReactDockerAWS
92%
of answers confirmed correct
How it was verifiedSubject-matter experts reviewed the assistant's answers to 500 test questions
15 → 3 min
average time to find information
How it was verifiedMeasured for the 80 employees using the assistant
Deliverables
What You Get and How You Verify It
Each stage ends with something you can inspect, and each item has an agreed way to check it before you sign off.
02
Working RAG system
PilotOne agreed use case
ProductionAll agreed sources, connected to your tools
How you verify itYour users test it hands-on with real questions
03
Quality evaluation report
PilotResults on the pilot test set
ProductionResults on the expanded test set, before go-live
How you verify itYour designated reviewer approves the results against the criteria described in the quality testing section below
04
Source code and deployment configuration
PilotPilot version
ProductionProduction version
How you verify itYour engineers review it; where it is hosted and who owns it are set in the contract
05
Documentation and handover
PilotArchitecture notes
ProductionArchitecture, operations runbook and admin guide
How you verify itYour team reviews it at handover; the contract sets which tasks move to your team and which stay with support
The quality of the handover stood out. We received the tests, the documentation and a clear process for updating the knowledge base. Before launch, outdated documents, access rights and unanswerable questions were all tested. Our engineers got to grips with the system and took over its support without needing the contractor for long.
Budget
What Determines Your RAG Development Budget
Two RAG systems with the same feature list can need very different amounts of work, because most of the effort sits in the data behind them. So we estimate each project from its inputs rather than from a price list.
- 1
You share the inputs
Which sources, how many users, access rules, where it runs, which tools and what a wrong answer costs you.
- 2
Per-module hour breakdown
Once you share these requirements, our Solutions Architect sends back a per-module hour breakdown.
- 3
Updated after the data audit
After the data audit, the estimate is updated with what the audit found in your sources.
- 4
Running costs after launch
Query volume and model choice move this number the most, so we model it from your expected usage as part of the estimate.
What Drives the Cost
01
Number and formats of sources
Clean text in one wiki is simple to index. Scanned PDFs, spreadsheets and complex tables need extra parsing and checking.
02
Data quality
Duplicates, outdated versions and contradicting documents have to be cleaned up or ranked, or the system will answer from the wrong one.
03
Access control requirements
Carrying permissions from SharePoint or a CRM into retrieval is separate engineering work.
04
Depth of quality testing
A support assistant for public docs needs less expert review than a tool your legal team relies on.
05
Integrations
Every target system adds authentication, interface and maintenance work.
06
Deployment model
A managed cloud setup is usually faster to stand up than a private cloud or on-premises deployment with a self-hosted model.
07
Query volume
It affects infrastructure sizing and model usage costs more than build effort.
For reference
The insurance assistant above covered 12,000 documents of three types with department-level access, and took a team of four 10 weeks.
A project with fewer sources and no access rules needs less. One with more integrations, stricter security or a self-hosted model needs more.
Running Costs After Launch
Once the system is live, you pay for LLM usage (per token through an API, or GPU hosting if the model runs in your environment), vector database hosting, compute for ingestion and sync jobs, and monitoring and logs. Add support time for fixing retrieval issues and re-running tests when content changes.
For a wider view of AI budgets, see our breakdown of AI app development cost.
Process
How the Project Runs
New builds usually move in four phases. Each one ends with a decision on your side before the next one starts. If you already have a RAG system, the work starts with a review of it instead, and the phases are adjusted to what needs fixing.
Discovery and data audit
What we need from you
Access to sample sources, an owner for each source, a security contact
Decision pointPilot scope: which use case, which sources, which users
Pilot
What we need from you
Subject-matter experts who write test questions and judge answers
Decision pointGo or no-go for production, based on the agreed quality criteria
Production build
What we need from you
Security and infrastructure requirements, access to the systems we integrate with
Decision pointAcceptance of the production system after final testing
Rollout and support
What we need from you
An owner for each source and a channel for user feedback
Decision pointWhich sources or use cases come next
The timeline is fixed after the data audit. By then we know how many documents need cleanup, how permissions are stored and which integrations are involved, and those factors move the schedule more than the feature list does.
Engagement Models
You don't have to commit to a full build up front. The engagement can start with discovery on its own, with a pilot, or with a review of a RAG system you already run.
Discovery on its ownData audit and an agreed pilot scope
PilotOne agreed use case, tested on your real questions
Review of an existing systemA review of a RAG system you already run
Data and security
Data, Integrations, and Security
Where the data comes from, how it stays current, who may see it and where the system runs are agreed before the build starts.
Data Sources and Integrations
Typical sources include PDF and Office files, Confluence, SharePoint, Notion, Google Drive, SQL databases and data warehouses, CRM and helpdesk records, and internal APIs. During ingestion, documents are parsed, split into passages, converted to embeddings and stored in a vector database along with metadata: source, date, owner and access rules. That metadata does real work later. It is what lets retrieval filter by permission or prefer the current version of a policy over last year's.
On the output side, the system can sit behind a chat interface, inside your product through an API, or in tools like Slack and your helpdesk. Whether a specific integration is practical depends on what that system's API actually exposes, so we check this during discovery. Our guide on how to integrate AI into an app covers the product side in more detail.
Sources
PDF and Office filesConfluenceSharePointNotionGoogle DriveSQL databasesData warehousesCRMHelpdeskInternal APIs
Output
Chat interfaceYour product, through an APISlackHelpdesk
Keeping Data Current
Indexing documents once is easy. Keeping the index in step with the sources is where production systems part ways with demos. Before the build, we agree on four things with you:
- 1How often each source is re-indexed, and whether changes are picked up incrementally or through a full rebuild
- 2How deleted documents are removed from the index so they stop appearing in answers
- 3How permission changes in a source system reach retrieval, and how quickly
- 4Who on your side owns each source and is responsible for keeping it accurate
Access Control
If your users should not all see the same documents, access control is a core requirement of the project. Permissions from source systems are not necessarily carried into retrieval automatically. They have to be stored with the indexed content and checked in the solution architecture, typically by filtering retrieved passages against the user's identity at query time through your SSO or identity provider.
OWASP describes what goes wrong without this in its LLM08:2025 Vector and Embedding Weaknesses entry, including data from one group being retrieved in answers to another group. If everyone in the company can read every source, this layer is much simpler.
Same question, filtered by identity · illustrative
Claims team
Claims proceduresPolicy termsHR files
HR team
HR filesPolicy termsClaims procedures
Deployment and Compliance Options
Where the system runs is decided during discovery: public cloud, private cloud (VPC) or on-premises, depending on your security requirements. The same goes for the model. Commercial LLM APIs are the simpler route, while an open-source model hosted in your environment is the usual choice when data cannot leave it.
The architecture can be designed to support requirements such as GDPR or HIPAA, for example by keeping data in a specific region or excluding certain fields from indexing. Compliance depends on your whole environment and processes, not on the RAG system alone, so we review the requirements with your compliance team during discovery.
Public cloud
Private cloud (VPC)
On-premises
Security work also covers prompt injection through retrieved content and leakage of sensitive data in answers. Both appear in the OWASP Top 10 for LLM Applications.
How We Approach the Architecture
The insurance assistant described above follows this pattern, with access split by department.
- 1Connectors pull content and permission data from each source on a schedule.
- 2Ingestion parses and cleans documents, splits them into passages and stores embeddings with metadata.
- 3At query time, the user's identity is resolved through SSO.
- 4Retrieval combines keyword and semantic search, filters results by the user's permissions and checks their relevance.
- 5The LLM is instructed to answer from the retrieved passages, cite them and say when they don't contain an answer. How well it follows these instructions is measured on the test set, as described in the next section.
- 6Logs of questions, retrieved passages and answers feed monitoring and future test sets.
Before the pilot, your security team should prepare a list of sources with an owner for each one. We also need to know which identity provider your users sign in with. Flag any data that must never be indexed, even if it sits in an approved source. Decide where data and models are allowed to run. Share your logging and retention requirements. Name the person who signs off on the security review.
Quality testing
How We Test Answer Quality Before Launch
Your experts define what a correct answer is. The system is tested on real questions from the people who will use it, and it goes to production only after your representative approves the results.
1
Collect
During the pilot, subject-matter experts collect questions users actually ask, from tickets, chats or search logs.
For each one, they write or approve the expected answer and the source it should come from.
After launch, the same test set is re-run whenever sources or models change, and real user questions with feedback are added to it over time.
2
Test
500questions in the insurance project's test set
It deliberately includes the cases where RAG systems tend to break:
- Questions the sources cannot answer
- Contradictory or outdated documents
- Documents users may not see
- Low-confidence cases
3
Decide
Results are reviewed with your designated representative, who approves or rejects them against criteria agreed before testing began.
Meets the criteria: production
Misses the criteria: three options
- Fix retrieval or the data
- Narrow the scope to the part that works
- Decide not to move to production
That decision is yours. It is much cheaper to make after a pilot than after a full build.
Alongside the expert review, we also track retrieval quality, faithfulness, citation accuracy and latency.
I doubted the assistant could make sense of our internal regulations, since even our departments sometimes read them differently. The pilot exposed the gaps, so we put the documents in order and refined the search. Now new employees find what they need faster, and managers spend less time explaining the same things again.
Custom or managed
Do You Need a Custom RAG Solution?
Custom development makes sense when your sources are complex or sensitive, when users need different access rights, or when the system must run in your environment or inside your product. For simpler cases, a managed RAG platform gets you to a working result faster.
Built for your case
Custom implementation
Best whenMany or unusual sources, strict access rules, integration into your product
Data and deployment controlYour choice of cloud, private cloud or on-premises, and of models
Integration depthConnectors built for your systems, within what their APIs expose
CustomizationRetrieval, ranking, prompts and interface built for your case
Time to first resultLonger, since it needs discovery and a build
Ongoing cost modelInfrastructure and model usage you control, plus maintenance
RAG as a service
Managed platform
Best whenStandard document Q&A over common file types and supported connectors
Data and deployment controlLimited to the vendor's hosting and model options
Integration depthThe platform's connectors and widgets
CustomizationConfiguration within the platform's settings
Time to first resultShorter for supported sources
Ongoing cost modelSubscription or usage fees set by the vendor
The two are not mutually exclusive
A custom system often uses managed components, such as a hosted vector database or a commercial LLM API; the insurance assistant above runs on the OpenAI API and AWS.
Fine-tuning is a different tool
It changes how a model behaves, such as its tone, output format or handling of domain terms, but it does not give the model access to your current documents. You can combine it with RAG when you need both up-to-date knowledge and a specific answer style.
If your project goes beyond retrieval, for example model selection or fine-tuning, see our LLM development services.
Choosing a vendor
Questions to Ask a RAG Development Company
These questions help you compare vendors on evidence rather than on claims.
- 01
Can you show measured results from a comparable project, and explain how they were measured?
- 02
Who decides what a correct answer is during testing, and what happens if the system misses the criteria?
- 03
How are source permissions stored and checked at query time?
- 04
Where will the system run, and where will our data and logs be stored?
- 05
What will it cost per month to run at our expected usage?
- 06
Who owns the code and the index after handover?
Questions and answers
FAQ
Ownership, data readiness, integration, stack choice and support after launch.
Your data remains yours at every stage. Ownership of the source code, configuration and index is set in the contract before work starts, so you know what you receive at handover.
No. Most teams start with messy sources. What matters at the start is knowing which documents are authoritative and who owns them. The data audit shows what needs cleaning, and the cleanup that affects answer quality becomes part of the project scope.
Yes. Retrieval and answer generation can be exposed as an API that your product calls. The main design questions are how your app passes the user's identity, so permissions apply, and how answers show their sources in your interface.
We choose after the data audit, based on where your data may be processed, expected query volume and results on your test set. The insurance assistant described above used Python, FastAPI, LangChain, PostgreSQL with pgvector and the OpenAI API on AWS. If data cannot leave your environment, an open-source model hosted on your infrastructure replaces the external API.
Support covers monitoring, fixing sync and retrieval issues, and re-running the test set after source or model changes. Adding new sources or use cases is development work and is scoped separately. The scope and response times of support are set in a separate agreement.
Contact
Tell Us About Your RAG Project
To get an estimate, send us the list of sources you want the system to use, the expected number of users and any security or deployment requirements.
Helpful to include
- The sources the system should use
- The expected number of users
- Security or deployment requirements
- Any RAG system you already run