How long does it take to build a production LLM application?

The two-week demo and the four-month system

You can build something impressive over a corpus of clean documents in two weeks. It will answer questions well, demo beautifully, and create an expectation that production is a fortnight away.

It is not, and the reason is worth being precise about. The demo works because it was run on the good documents, by people who knew what to ask, with no permissions, no logging, no error handling and no measurement. Production has to work on the whole corpus, for people who ask badly, under access control, with evidence that it works.

Where the time actually goes

For a typical 12-week production build:

Weeks 1 to 2. Corpus reality check and evaluation set. What the documents really look like, and a labelled set of real questions with known-correct passages. Skipping this is the most expensive shortcut available.

Weeks 3 to 5. Ingestion and parsing. Consistently the largest and most underestimated block. Scanned pages need OCR. Tables need structural extraction. Documents exported from legacy systems arrive with the structure stripped out.

Weeks 5 to 8. Retrieval engineering. Chunking, embedding choice, hybrid search weighting and metadata filters, all run as experiments against the labelled set rather than as preferences.

Weeks 7 to 10. Application layer. Generation with citations and refusal behaviour, conversation handling, permission enforcement at retrieval time, the interface.

Weeks 9 to 12. Hardening and handover. Observability, cost controls, rate limiting, failure paths, runbook, load testing, and the sessions that leave your team able to change it.

The overlaps are intentional; these tracks run in parallel.

What causes overrun

1. Document quality found late. Knowable in week one if anyone samples the corpus properly. Frequently is not.
2. Permission requirements found late. “Everyone can see everything” becomes “actually, four access tiers and regional restrictions” in week eight, and that reshapes retrieval.
3. No evaluation set. Without one, retrieval tuning becomes an endless subjective argument nobody can close.
4. Scope drift after the demo. The demo is so encouraging that three more departments want their corpus in it.
5. Waiting on source system access. Nearly always the long pole, and nearly always started too late. Begin the access requests in week one.

Compressing it honestly

You can go faster by narrowing scope, not by skipping stages. One corpus, one user group, one clearly defined question type, shipped in eight weeks, beats four corpora shipped in twenty-four, and it produces the evidence you need to justify the next phase.

The stages that look optional are the ones that determine whether the system survives its first month with real users.