Pricing a RAG Project Before You Have Requirements

Somebody has asked what a document assistant would cost, and they want a number this week. Refusing until requirements exist is correct and useless. The workable move is to give a range, state the three variables that determine where in the range it lands, and make clear which parts of the estimate are fixed and which scale.

The technique is to price the structure rather than the scope. The structure is knowable now; the scope is not.

Split the estimate into four terms, always

Any number you give should be visibly composed of these, because a single figure invites the wrong conversation and a composed figure invites the right one.

Build      = one-off engineering to first release
Run        = per-request inference + storage, scaling with traffic
Maintain   = permanent fractional staffing, per month, forever
Change     = the redesigns you can already see coming

Sponsors hear a single number as the whole cost, and the term they most need to see is Maintain, because it is the one that recurs and the one that kills projects when unfunded. Presenting four terms also protects you: when the scope grows later, you can show which term absorbed it.

The three questions that collapse the uncertainty

Most of the variance in a pre-requirements estimate comes from three unknowns. Get rough answers and your range narrows dramatically.

1. How many source systems? Not how many documents — how many places the documents live, and how weird each one is. One well-organised wiki is a fraction of the work of six systems including a legacy platform with no API and a shared drive of scanned PDFs. This is the single biggest driver of build cost, and it is answerable in a meeting.

2. Does everyone see everything? If yes, permissions are a non-problem. If no, you have a permission-aware retrieval design, which is a substantial multiplier on both build and maintenance — and, as noted in scaling thresholds for a retrieval system, the hardest thing to retrofit.

3. What is the consequence of a wrong answer? This determines whether you need a review step, an approval workflow, a refusal policy, and the measurement apparatus to support them. An internal engineering-docs assistant and a customer-facing policy answerer are not the same project even with an identical corpus. The sizing method is in the cost of being wrong.

Ask exactly those three. Everything else — chunk sizes, which model, which vector store — moves the estimate far less than any of them, though it will dominate the conversation if you let it.

A worked estimate with labelled hypothetical inputs

Every figure below is invented for the illustration. The point is the arithmetic and the shape, not the numbers; substitute your own rates and your own answers.

Scenario: two source systems, both with APIs, all staff see everything, internal audience, wrong answers embarrassing but not costly.

Build. Ingestion for two systems, chunking, embedding, retrieve-and-generate path, a simple UI, and a small eval set. Call it eight engineer-weeks. At a hypothetical loaded rate of $4,000 per engineer-week: $32,000.

Run. Say 1,500 queries a day, 4,000 input and 400 output tokens per answer. At hypothetical prices of $3 per million input and $15 per million output tokens: 6M input and 0.6M output daily, so $18 plus $9 — about $27 a day, roughly $800 a month. Storage and embedding for a modest corpus: call it another $150.

Maintain. 35% of an engineer plus a little domain-expert time. At a hypothetical $16,000 loaded monthly cost: about $5,600 a month.

Change. One foreseeable item — a third source system in year two: $8,000, flagged rather than included.

First-year total, hypothetical: $32,000 plus twelve months at roughly $6,550, so about $110,000, of which around 70% is people doing maintenance rather than anything that looks like the project.

That ratio is the finding to lead with. It is stable across a wide range of assumptions, and it reframes the sponsor’s question from “can we afford to build it” to “can we afford to keep it,” which is the question that matters.

How the answers move the estimate

Change to the scenario	Effect
Six source systems instead of two, one without an API	Build roughly doubles or worse; Maintain rises
Per-user permissions	Build up substantially; Maintain up; adds a permanent correctness obligation
Customer-facing with policy consequences	Adds review workflow, refusal policy, and real measurement — a different project
20× the query volume	Run becomes the dominant term; caching and model tiering become worth engineering
Corpus updates hourly rather than nightly	Ingestion redesign; see choosing a freshness requirement you can afford
Scanned or heavily tabular documents	Extraction becomes its own workstream, and it is easy to underestimate

Bring that table to the meeting rather than a single figure. It converts an argument about your estimate into a conversation about their scope, which is the conversation you want and the one that produces requirements.

Three ways these estimates go wrong

Pricing the prototype. A demo over clean documents is a genuinely small piece of work, and it is a bad predictor of the rest. The gap is permissions, extraction from ugly formats, measurement, and the maintenance commitment — none of which the prototype exercises. Say so when you show the demo, in the same breath.

Omitting the corpus work. Somebody has to decide what is authoritative, and if the answer is “nobody yet,” that is a project dependency, not a detail. Put it in the estimate as work even though it is not engineering work.

Quoting only the vendor fee for the buy option. Integration engineering against a platform is real and frequently comparable to the subscription. Both columns in build or buy your retrieval stack have an engineering term.

The recommendation

Give a range with the three questions attached, and refuse to give a single number. Something like: eight to twenty engineer-weeks to build, plus a third of an engineer permanently, and here are the three answers that decide where in that range you land. That is defensible, it is honest, and it makes the sponsor a participant in narrowing it.

Lead with the Maintain term, not the Build term. It is the larger figure over any horizon longer than a year, and the entire failure pattern of retrieval projects is funding the first and not the second.

Spend a week before quoting, if you can get one. Evaluate whatever assistant your suite already includes, per the assistant you already pay for, and collect thirty real questions. Both artefacts sharpen the estimate more than a fortnight of design discussion, and one of them occasionally makes the project unnecessary.

The threshold that flips the whole exercise: if the projected annual Run cost is small relative to the Maintain cost — which is the normal case at internal volumes — then efficiency work is not where the money is, and you should be estimating and negotiating people rather than tokens. Check the composition in what a RAG system actually costs to run before optimising anything.