Generative AI and LLM Engineering
Custom LLM applications, retrieval systems and fine-tuned models grounded in your own data, not a public chatbot with your logo on it. Twelve engagements, each with its own scope, price and output.
The model is the easy part.
Foundation models are a commodity and getting cheaper every quarter. What decides whether a generative AI feature survives contact with real users is the engineering around it: what it retrieves, how its context is assembled, how quality is measured, what it costs at ten times the current volume, and what happens when someone puts an instruction inside a document it reads.
Every engagement in this pillar is built around a measured baseline. We agree what good looks like, score it before we change anything, and score it again after, so improvement is a number you can inspect rather than a claim you have to accept.
What we build
Each is a standalone engagement with its own scope, price and output. Most clients use two or three in sequence.
Custom LLM Application Development
A production LLM application built on your data, with evaluation, guardrails and cost control designed in rather than added later.
Read more →RAG System Development
Retrieval augmented generation built as a measured retrieval problem, with chunking, hybrid search, reranking and evaluation.
Read more →LLM Fine-Tuning and Customisation
Fine-tuning when prompting and retrieval have genuinely run out, with curated data, a measured baseline and a clear verdict.
Read more →Prompt and Context Engineering
Prompts treated as versioned, tested software: context budgets, regression suites and measured improvement rather than trial and error.
Read more →LLM Evaluation and Benchmarking
Golden sets, calibrated judges and a regression suite in CI, so quality is a number that moves rather than an opinion.
Read more →Private and Self-Hosted LLM Deployment
Open-weight models served inside your own tenancy or data centre, with honest GPU sizing and throughput economics.
Read more →Small Language Models and On-Device AI
Task-specific small models that run on a phone, laptop or edge device, with low latency and no data leaving it.
Read more →Multimodal AI Development
Systems that read documents, images, audio and video together, with grounding, verification and per-modality scoring.
Read more →Model Distillation and Inference Optimisation
Cost and latency reduced through routing, caching, quantisation and distillation, with quality held to an agreed floor.
Read more →Synthetic Data Generation
Generated datasets for training and testing, with fidelity checks, privacy leakage testing and honest limits.
Read more →AI Copilot Development
A copilot inside the tool people already use, scoped to real workflows, with the user always in control.
Read more →Enterprise Knowledge Assistant
Internal search that answers with citations, honours existing permissions and says when it does not know.
Read more →How they fit together
You do not need all twelve. Most programmes follow one of these paths depending on where the uncertainty sits.
Nothing built yet
Start with a proof of concept or a scoped application build. Retrieval design and the evaluation set come with it, because retrofitting either one is considerably more expensive than including it.
Built, but quality is inconsistent
Evaluation first, so the problem can be located, then prompt and context engineering or RAG work depending on what the scores say. Fine-tuning only if a measured baseline shows prompting has genuinely run out.
Working, but too expensive or too exposed
Inference optimisation for unit cost and latency, private deployment where data cannot leave your boundary, and small or distilled models where the task is narrow enough to run on hardware you already own.
FAQ
Marked up with FAQPage schema so these answers can surface in search results and inside AI assistant responses.
Where should we start with generative AI?
If nothing is built, with a narrow use case and a proof of concept rather than a platform. If something is built and quality is uneven, with evaluation, because until quality is measured every change is a guess. If you are not yet sure which use case is worth building at all, start with AI use case discovery in the consulting pillar.
Do we need RAG, fine-tuning, or both?
Retrieval supplies facts at request time and is right for knowledge that changes. Fine-tuning changes behaviour, format and tone and is right for consistency at volume. Many production systems use both. Choosing without measuring a prompting baseline first is how budgets get spent on the wrong one.
Are these engagements tied to one model provider?
No. We build against an abstraction so the underlying model can be changed, and we benchmark candidates on your evaluation set rather than on public leaderboards. Where the choice is contested before a build begins, AI vendor and model selection settles it with evidence.
How are these engagements priced?
Fixed scope and fixed price for defined builds, with milestones on longer engagements. Indicative ranges are published rather than quoted only on request, and every engagement can stop at a stage boundary with everything produced up to that point transferring to you.
Who owns the code, prompts and model weights?
You do, in full, on final payment. That includes prompts, evaluation sets, curated training data, fine-tuned weights and infrastructure as code, so nothing about the system depends on us remaining involved.
Start with a conversation.
Thirty minutes, no charge, no deck. Tell us what you are trying to build with language models and we will tell you which of these engagements fits, or whether none of them do.