SERVICE

LLM development

Language models wired into your systems, with the failure behaviour designed.

What this actually is

LLM development is mostly not model training. It is retrieval, context construction, tool access, evaluation and the decisions about what the system must refuse — the parts that determine whether a demo survives contact with real users.

The default architecture is retrieval, because facts change and weights do not. Fine-tuning earns its place when behaviour is the problem: a consistent tone, a strict output schema, a classification that prompting cannot make reliable.

What we do

  1. Architecture

    Which model, hosted where, with what retrieval and what tools. Driven by your latency, cost and data-residency constraints rather than by what is newest.

  2. Context engineering

    What the model sees and in what order, within a token budget. This moves quality more than model choice does, and it is where most of the tuning happens.

  3. Evaluation

    A held-out question set with known answers, run on every change. Without it a prompt tweak that quietly breaks something ships unnoticed.

  4. Guardrails

    Refusal behaviour, scope limits, PII handling and the escalation path — designed before launch rather than added after an incident.

  5. Cost control

    Caching, batching, model routing and quantisation. Inference cost is a per-request variable that compounds quietly at scale.

The stack

PythonLangGraphOpenAI, Anthropic and open-weight modelsvLLMpgvector, Qdrant, PineconeLoRA / PEFT where fine-tuning is warrantedWeights & Biases

What it connects to

Integration surface is the honest driver of effort — ten systems is not ten times one system.

How a project runs

Scoping

1 week

The task, the quality bar, and what the system must refuse to do.

Baseline

1–2 weeks

The simplest thing that could work, measured — often stronger than expected.

Build

4–8 weeks

Retrieval, tools and guardrails, with evaluation running on every change.

Hardening

2 weeks

Latency, cost, failure paths and monitoring for quality drift.

Where teams use it

Support

Grounded answering with citations and a clean handover to a human.

Legal and compliance

Document summarisation where the citation matters as much as the summary.

Internal knowledge

Search across systems that were never designed to be searched together.

Structured extraction

Turning unstructured documents into records a system can act on.

Agentic workflows

Multi-step tasks with scoped tool access and an audit trail of each decision.

When this is the wrong answer

If the task is deterministic, use code. An LLM is slower, more expensive and less reliable than a function for anything with a correct answer you can compute.

Fine-tuning does not reliably teach facts. Teams reach for it to fix knowledge problems and get a model that is confidently wrong in a more consistent tone.

Evaluation is the difference between a system you can improve and one you can only hope about. If there is no held-out set, changes are guesses.

Inference cost scales with usage in a way that surprises people. It belongs in the business case from the start, priced per interaction rather than per month.

Proof

SiteChat & Estimate256: RAG bots and ML estimation in production

Zero-code website chatbot platform plus a domain-tuned ML estimation engine — two production systems on one modern stack.

Any URL to chatbot, zero code3 domain-tuned XGBoost models

Frequently asked questions

Should we use an API or self-host?

API for most cases — better models, no operations burden. Self-host where data residency, cost at very high volume, or latency genuinely require it. That is a smaller set of cases than vendors of self-hosting suggest.

Which model should we use?

Whichever passes your evaluation set at acceptable latency and cost. We build the harness so this is a measurement rather than an opinion, and so switching later is cheap.

How do you stop it going off-topic?

Scope limits in the system prompt, retrieval that only returns in-scope content, and output validation. Not perfect, and measurable — which is what lets it be improved.

Do you fine-tune?

When behaviour rather than knowledge is the problem. We will usually try prompting and retrieval first, because they are reversible in an afternoon and a fine-tune is not.

Who owns the code?

You do, from the first commit — work happens in your repository under your licence, and the contract assigns IP outright. We keep no rights and build no dependency that makes leaving expensive.

What does it cost?

We do not publish a number, because the honest one depends on scope, integrations and the accuracy bar. Tell us the budget you are working with and we will say what it buys — or say plainly if it does not buy enough.

Related

Before you choose anyone

Written to be useful whether or not you hire us — including the parts that argue against hiring an agency at all.

LLM & Foundation Model Development — tell us the scope

Tell us what you are building. We reply within one business day.