Who owns the code and the model accounts?

You do, from the first commit. Everything runs in your repositories and your provider accounts. There is no platform to be locked into and nothing to migrate off later.

LLM Application Development — AI Agents, RAG Pipelines and Evals

Most demos stop at the middle column. What survives real users is everything after it.

   ingest            index              retrieve            generate
   ──────            ─────              ────────            ────────

   documents  ────►  chunks       ────►  top-k       ────►  model      ────►  answer
   database          + vectors          + rerank            + tools
   API feeds         + metadata         + filters           + guardrails
       │                                                        │
       │                                                        ▼
       │                                                   fallback when
       │                                                   the answer is
       │                                                   not good enough
       ▼
   ┌───────────────────────────────────────────────────────────────────┐
   │  evals   a fixed set of cases with known-good answers,           │
   │           replayed on every change before it reaches users        │
   └───────────────────────────────────────────────────────────────────┘

 ingest
 documents · database · API feeds
     │
     ▼
 index
 chunks + vectors + metadata
     │
     ▼
 retrieve
 top-k + rerank + filters
     │
     ▼
 generate
 model + tools + guardrails
     │
     ▼
 answer  (with a fallback when
          it is not good enough)

 ┌──────────────────────────────┐
 │ evals — known-good cases,    │
 │ replayed on every change     │
 │ before it reaches users      │
 └──────────────────────────────┘

The reranking, the fallbacks and the eval set are the parts that get skipped in a demo and then rebuilt in a panic. Here they are scoped from the start, not added after the first complaint.

What it covers

LLM applications The product itself: the interface people use, the orchestration behind it, and what happens when a model returns something useless.

Retrieval pipelines Ingestion, chunking, embeddings and reranking over your documents or database. Usually the difference between a convincing demo and something that survives real questions.

Agents and tool use Systems that call your APIs and act on the results, with the guardrails that stop them acting on a bad one.

Evals and monitoring A case set with known-good answers, replayed on every change, plus logging of what users actually asked and what came back.

Cost and latency Model routing, caching and prompt shape — the boring layer that decides whether the unit economics work at scale.

Self-hosted models Open-weight models on your own hardware when the data cannot leave. Priced honestly, including what it costs in quality.

How it runs

Scope

Which decision this augments, what data exists, and what “working” would have to mean. If a model is not needed, that comes up here.
Prototype on real data

Two to three weeks to something running on your actual documents or database, not sample text. This is where most assumptions die cheaply.
Evals before scale

The case set is written from the failures the prototype produced, so quality becomes a number instead of an opinion.
Production

Auth, rate limits, logging, cost controls — the unglamorous parts that decide whether it survives its first real month.
Handover

Your repositories, your accounts, written down so the next engineer can carry it without a phone call.
Optional: keep going

A retainer if you would rather the same hands stayed on it while it grows. Decided before the build, not after.

What you end up owning

The application, in your repository, from the first commit
The eval set and the harness that runs it
Infrastructure as code, plus the accounts it runs on
A written map of how it works and where it breaks
Cost model: what each request costs and why
The list of what was deliberately left out, and when to revisit it

Terms

Prototype

2–3 weeks

To production

6–12 weeks

Engagement

Fixed scope, quoted after the first call

Stack

TypeScript, Python, Postgres, pgvector

Not a fit if

You need a model trained from scratch — that is a research budget, not a product one
There is no data yet and no plan to get any
The requirement is “add AI” without a decision it is meant to improve
Accuracy has to be provably perfect — language models are not the right tool for that

Questions that come up first

Fine-tune, or use retrieval?

Retrieval first, almost always. Fine-tuning changes how a model behaves, not what it knows, and it ties you to a model version you will want to leave. Most problems that look like fine-tuning problems are retrieval problems with a bad chunking strategy.

How long does a prototype take?

Two to three weeks for something running on your data, not a demo on sample text. Production usually lands between six and twelve weeks, depending on integrations and how clean the data turns out to be.

How do you know it is actually working?

The eval harness is part of the build, not an extra line item. Cases with known-good answers, replayed on every change, so a prompt edit that quietly breaks a feature is caught before your users find it.

Who owns the code and the accounts?

You do, from the first commit. Everything runs in your repositories and your provider accounts. Nothing to migrate off later, because nothing ever lived somewhere else.

What if we do not actually need AI?

Then that is what the first call concludes, and it costs nothing. A rules engine, a search index or one good query often beats a model — cheaper to run, easier to debug, and it does not hallucinate.

Can it run on our own infrastructure?

Yes. Open-weight models can be served on your hardware or private cloud when data cannot leave. It costs more engineering and usually some quality — that trade-off gets priced before you commit to it.

AI product development