How long does RAG development services take? A realistic timeline
How long does RAG development services take?
Most RAG development services engagements take eight to sixteen weeks from kickoff to a staged production launch. A single-source assistant lands near eight weeks; a permission-aware build across five repositories takes sixteen or more. Source access, not engineering, is the usual reason the date moves.
Most RAG development services engagements take eight to sixteen weeks from kickoff to a staged production launch. A single-source assistant over content you can already export lands near eight weeks. A permission-aware build across five repositories with regulated documents takes sixteen or more. Getting credentialled access to the source systems, not the engineering, is the usual reason a date moves.
This article lays out the calendar block by block, names what has to be true on your side for each block to finish, separates the work that genuinely runs in parallel from the work that cannot, and is specific about the four things that reliably add weeks. Treat it as a planning document rather than a sales promise.
The calendar in one table
Below is the shape of a mid-sized engagement: three to five content sources, permission-aware retrieval, an evaluation suite and a staged rollout. Smaller builds compress the middle blocks; regulated builds extend the last.
| Block | Weeks | What you must supply | What comes out | What stalls it |
|---|---|---|---|---|
| Scope and question set | 1 to 2 | Two to four hours a week from people who answer these questions today | Golden question set, source list, architecture decisions, success thresholds | Nobody can agree which questions matter |
| Access and ingestion | 3 to 5 | Credentials, API quotas, a sandbox copy of each source | Incremental connectors, parsing, chunking, metadata and permissions captured | Security review of a service account, or unparseable scanned content |
| Retrieval and generation | 2 to 3 | A reviewer who can judge answer quality | Hybrid search, reranking, permission filtering, citations, refusal behaviour | Retrieval misses on a document type nobody mentioned in scoping |
| Evaluation and hardening | 1 to 2 | Sign-off on the accuracy threshold | Measured recall, precision and groundedness, tracing, cost dashboards | The threshold was never agreed, so nothing can be declared done |
| Staged rollout | 2 to 4 | One pilot team and a named owner for weekly review | Feature-flagged launch, feedback loop, content fixes, runbooks and handover | No owner for the flagged answers, so the loop never closes |
Read the last column first. Four of the five stalls are organisational rather than technical, which matches what we see: engineering teams rarely miss RAG dates because the code is hard.
What actually happens in each block
Weeks 1 to 2: agreeing what correct means
The output of the first fortnight is not code. It is a set of one hundred to three hundred real questions with the sources that correctly answer each, an agreed list of content sources, and a written decision on chunking, embedding model, index location and how permissions will be carried. Those decisions are expensive to reverse after a corpus is indexed, which is why they get a fortnight rather than an afternoon. The implementation guide sets out each decision and its reversal cost.
Weeks 3 to 7: the block that decides the date
Ingestion is the longest and most variable block. Each source needs authenticated incremental access, parsing that survives the awkward formats, chunking tuned to the document type, and metadata including access groups captured at write time. Where the index lives matters less to the schedule than people expect: keeping vectors in an existing Postgres using the pgvector extension, which adds vector types and approximate nearest-neighbour indexes to the database you already run, removes a procurement cycle that on its own can cost three weeks.
Weeks 8 to 10: retrieval, then language
Hybrid search, reranking and the permission filter come first, and only then the generation prompt with citations and an honest refusal path. Teams that invert this order spend the block tuning prompts to compensate for retrieval that is returning the wrong passages, which never works and always overruns.
Weeks 11 to 16: proving it, then releasing it slowly
Evaluation runs the golden question set on every change and reports recall, precision, groundedness and refusal accuracy. Rollout is one team behind a feature flag, with every answer logged next to its retrieved passages and a one-click way to flag a bad one. Expect most week-one fixes to be content fixes rather than model fixes, and leave calendar room for them.
Handover belongs in this block too, not after it. Runbooks, the prompt history, the re-indexing schedule and a walkthrough of the evaluation harness are deliverables with dates, because a system your team cannot re-run next quarter is a system that quietly stops being measured.
What genuinely runs in parallel
Compression comes from overlapping tracks, not from working faster. These five can run alongside the critical path if you staff them.
- Question set and access requests. Start the security paperwork for every source in week one, while the question set is being written.
- Interface build and retrieval build. The front end can be built against a stubbed retrieval response and swapped later.
- Content remediation. Archiving superseded documents and writing missing pages can start the day the source list is agreed.
- Evaluation harness and pipeline. The scoring code is written while ingestion is still running, so the first measurement lands the day the index does.
- Security review and build. Threat modelling, redaction rules and data residency decisions belong in weeks one to four, not week twelve.
What cannot be parallelised is proof. You cannot evaluate retrieval before content is indexed, and you cannot roll out before the threshold is met. Any plan that overlaps those is a plan to launch something unmeasured.
What adds weeks
Four causes account for most of the slippage we see, and three of them are visible before kickoff if anyone asks.
Source access is the largest. A service account for SharePoint or a ticketing system can take two to four weeks to approve in an enterprise, and no engineering effort compensates. Ask for the credentials in the first week, in writing, with a named approver.
Unparseable content is the second. Scanned PDFs, spreadsheets used as databases and drawings all need bespoke extraction. Sample a hundred real documents during scoping and you will know; skip that and you will find out in week five.
Scope drift is the third. Two extra sources added in week six do not cost two connectors, they cost connectors plus re-chunking, re-indexing, an expanded question set and a fresh evaluation run. We hold scope explicitly for this reason, as described in scope lock.
Undefined acceptance is the fourth and the most avoidable. If nobody has agreed what recall the system must hit before it goes live, the project cannot end, and the last block expands indefinitely while opinions are collected.
How to compress it honestly
Narrow the first release to one question class, two sources and one team. That reliably reaches production in around eight weeks and produces something measurable, and the second phase is faster because the pipeline, evaluation harness and access paths already exist. Building an enterprise-wide assistant over Drive, Slack and a wiki in a single release, as described in our enterprise knowledge assistant build guide, is achievable but should be planned as phases rather than a single date.
Where the corpus is genuinely unknown, buy the answer before the schedule. A ten-day Discovery Sprint at $3,250 or ₹2,00,000, credited against the build, produces the scope and the question set. A three-week AI POC Sprint at $6,250 to $10,500, or ₹4,00,000 to ₹6,80,000, indexes a slice of the real content and reports measured recall, which turns a sixteen-week estimate into a commitment.
When a fast timeline is the wrong goal
Two situations make speed the wrong objective. If the content is thin or contradictory, shipping quickly just puts a confident wrong answer in front of users, and the fastest genuine path is to fix the corpus first. If the system will answer regulated questions, on lending, claims or clinical matters, the review cycle that feels like delay is the control that makes the system usable at all; compressing it moves risk rather than removing it.
There is also a quieter case. If your organisation cannot free subject-matter experts for two to four hours a week, a compressed timeline is fiction regardless of how the plan is drawn, and the honest answer is to wait for a quarter when they are available.
Cost against the calendar
Our retrieval and knowledge engineering programme runs from $14,000 to $49,000, or ₹8,80,000 to ₹32,00,000, fixed price against a locked scope, which is what makes a fixed date possible: the date and the price move together or not at all. After launch, the monthly cadence of re-indexing, evaluation and cost review sits in a Care Plan from $1,000 or ₹68,000 a month, with the AI add-on at $750 or ₹40,000. Both are published on the pricing page.
On team shape, a mid-sized build runs with an AI engineer, a backend engineer for connectors and access control, a designer or front-end engineer part time, and a delivery lead. On your side the commitment is smaller but non-negotiable: a product owner who can decide scope, a subject-matter expert for the question set and answer review, and someone in IT who can obtain credentials. About half our engagements pair with an internal team and end in documented handover, which adds no weeks if it is planned from week one and adds several if it is remembered at the end.
Related reading
What RAG development services cost in 2026 maps the same scope bands onto price, and five ways RAG projects fail covers what happens when the blocks above are run out of order.
Ask for the source credentials in week one and you will know by week three whether your sixteen-week plan is real.
Frequently asked questions
How long does a RAG project take from kickoff to launch?
▾
Eight to sixteen weeks for most scoped builds. Roughly two weeks on the question set and architecture decisions, three to five on access and ingestion, two to three on retrieval and generation, one to two on evaluation, then two to four weeks of staged rollout behind a feature flag with a pilot team.
What is the biggest cause of delay in a RAG build?
▾
Getting credentialled access to source systems. A service account for SharePoint, Drive or a ticketing platform can take two to four weeks to approve in an enterprise, and no amount of engineering compensates. Request credentials in week one, in writing, with a named approver on your side.
Can a RAG system be delivered faster than eight weeks?
▾
Yes, if you narrow the release to one question class, two content sources and one pilot team, and the content is already exportable and clean. A three-week POC Sprint on a slice of the real corpus is the faster honest option when you need measured evidence before committing to a full build.