How long does an enterprise LLM project take, and what does it cost?

There is a reason the budget question in AI projects rarely gets a straight answer: it is usually asked in the wrong unit. "How much does a chatbot cost?" is about as precise as "how much does a building cost?". What can be explained is where the cost comes from and what sets the timeline. This article answers those two questions, not with figures.

Which stages does an LLM project go through?

The total length of these stages varies between organisations, and the reason is not technical. In practice the most common cause of delay is organisational: getting access to the data approved, legal sign-off, or stakeholders failing to agree on scope. If those three move quickly, the project moves quickly; if they do not, no technical decision makes up for it.

What does the cost consist of?

Think of two separate budgets: a one-off build and an ongoing running cost.

Build (one-off)

Team size multiplied by time. A small, mixed team is enough for an enterprise LLM project: an AI engineer, a software engineer and a part-time domain expert. A larger team does not make this kind of project faster; it adds integration and decision overhead.

Running (monthly)

• Model usage: A price per token, in direct proportion to query volume and context length.
• Infrastructure: Vector database, application server, monitoring, backups.
• Maintenance: The document update flow, keeping the evaluation set current, tracking model versions.

A common misconception is that the whole running cost is tokens. In most internal systems tokens are a small item in the monthly bill; the real cost is people's time and infrastructure. The balance flips for external, high volume products, where token optimisation moves to the centre of the architecture.

What actually reduces the cost?

1. Model routing. Not every question needs the strongest model. A layer that sends simple questions to a small model and complex ones to a large model cuts cost without a noticeable drop in quality.
2. Caching. In enterprise use, questions repeat. A semantic cache stops the same question from reaching the model twice.
3. Context discipline. Sending ten documents with every query does not raise accuracy; it adds noise and multiplies the cost. A good reranking layer is both cheaper and more accurate.
4. Prompt length. Long system prompts are charged again on every query. With providers that support prompt caching, this item drops noticeably.

Items nobody budgets for, but always appear

The three items most often left out:

• Data cleaning. Document archives are never tidy: three versions of the same file, scanned PDFs, empty templates. This work is in nobody's plan, yet it shows up in every project.
• Evaluation infrastructure. A test set that measures the system's accuracy is not a nice to have; it is a basic requirement. Without it, nothing can be improved.
• User training and adoption. A system that works technically but that nobody uses is a failed system. Adoption work is part of the project.

How do you measure the return?

Pick a single number before the project starts and start measuring it from day one. Good metrics are concrete and comparable with today: the average time to answer a request, the time spent searching a document for information, the number of records processed by hand.

A bad metric is "user satisfaction": it is measured late, it changes late and it does not tell you what worked. A baseline measurement taken before the system goes live shortens every discussion that comes after.

Summary

A realistic plan looks like this: a short feasibility study, then a decision. If the decision is positive, a narrow pilot and a measurable result. If the result is good enough, the production work. The length of each stage is set once the scope is clear. The one thing that breaks the schedule is scope growing along the way, and the only way to prevent that is to put in writing, on the first day, what is out of scope.