Model selection, retrieval, fine-tuning, evaluation, guardrails, and deployment, including self-hosted, where your data can't leave your environment. This is the part that decides whether an AI system holds up in production or quietly degrades after launch.
Fixed scope or retainer · You own the weights, the code, and the pipeline
Infrastructure
Your cloud, your region, or on-premise
Model
Commercial APIs and open-weight models
Retrieval & context
Vector and hybrid search, chunking, reranking
Orchestration & tools
Function calling, multi-step flows, MCP
Evaluation & guardrails
Test sets, regression suites, drift monitoring
Agents, chatbots, assistants — see Section 9
Almost every "should we build a custom LLM?" conversation is really this question, and it gets answered badly because most people answering it sell one specific option. There are five approaches. They're ordered by cost and complexity, and the right answer is nearly always the first one that works.
| Approach | Solves | Typical cost | When it's right |
|---|---|---|---|
| 1. Prompt and context engineering | The model has the capability but not the instruction | Lowest | Almost always try first. A surprising share of “we need a custom model” problems are solved here. |
| 2. Retrieval (RAG) | The model doesn’t know your information | Low–moderate | The default answer for anything involving your documents, policies, or records. |
| 3. Tool use and orchestration | The model needs to look things up or take action | Moderate | When the answer lives in a live system rather than a document. |
| 4. Fine-tuning | The model knows the facts but not the form, your tone, format, or a specialised task | Moderate–high | Consistency of output, narrow classification, or reducing cost by moving work to a smaller model. |
| 5. Training from scratch | Almost nothing you will encounter | Very high | Effectively never for a business application. If someone proposes it, ask what problem the previous four failed to solve. |
Fine-tuning does not teach a model your facts. It teaches it a behaviour, a style, or a task. If the model needs to know your refund policy, retrieval is the answer, and fine-tuning it in makes the information harder to update rather than easier. This single misunderstanding is behind most wasted fine-tuning budgets.
Fine-tuning is often the cost answer, not the capability answer. The strongest real case for it is taking a task a large model already does well and moving it to a smaller, cheaper, faster model that's been tuned for exactly that task. That's an economics decision, and it only makes sense once you have volume.
You need evaluation before you need any of them. Without a test set, you can't tell whether the fine-tune helped, whether the retrieval change improved anything, or whether last month's model update broke something. Teams routinely skip this and then argue about whether the system is getting worse based on anecdotes.
Our default position: prompting and retrieval solve the large majority of business problems. We'll propose fine-tuning when there's a specific reason, and we'll tell you what that reason is.
Commercial APIs and open-weight models, chosen per task rather than standardised across a project. Most production systems end up using more than one: a capable model where reasoning matters, a small fast one for classification and routing, and often an embedding model that has nothing to do with either.
We build the model layer behind an abstraction so switching providers is a configuration change, not a rewrite. This field moves fast enough that designing for replaceability is basic engineering hygiene, not future-proofing.
We deliberately don’t name specific model versions on this page, anything we listed would be stale within a quarter. On a call we’ll tell you exactly what we’d use for your task and why.
Self-hosting an open-weight model is a serious commitment. There are three good reasons for it and a lot of bad ones.
Some data legitimately cannot leave your infrastructure, regulated sectors, government work, contractual obligations to your own clients, or a jurisdiction with strict residency rules. This is the strongest reason and the one that decides it most often.
Above a certain steady throughput, dedicated inference becomes cheaper than per-token API pricing. That crossover point is much higher than most people assume, and it moves every time providers cut prices, which they keep doing.
A self-hosted model doesn’t change underneath you. If you need output that’s identical in twelve months, you need a model that’s still there in twelve months.
Self-hosting means you own the GPU bill whether the system is busy or idle, you own the upgrade path, and you own the operational burden. The frontier commercial models generally remain more capable than what you can practically self-host, so on the hardest reasoning tasks you may be trading capability for control.
Most clients who ask about self-hosting turn out to need one specific thing kept in-house, not everything. A hybrid, sensitive work on a self-hosted model, general work on an API, is usually cheaper and better than either extreme. That's a design decision worth making deliberately rather than defaulting to one side of it.
Ask a vendor how they'll know the system is working and listen carefully to the answer. If it's a demo, that isn't an answer.
Actual questions with agreed correct answers, built with your team, covering the normal cases and the awkward ones. This is the artefact everything else depends on.
Prompt changes, retrieval changes, and model updates all get run against the test set first. Without this you’re changing a production system on instinct.
Provider models get updated, your data changes, and your users ask things nobody anticipated. Accuracy drifts. Drift you can see is a maintenance task; drift you can’t see is a slow failure.
Every question the system couldn’t answer is logged. Once a month we decide what should have been answerable and close the gap. Coverage goes up over time rather than sitting where it launched.
This is a summary of the engineering implications, not legal advice, take your own.
If you serve UK or EU customers, this is live now rather than upcoming.
Already in force. Prohibited practices have applied since February 2025. Obligations on general-purpose AI model providers have applied since August 2025. The Act's general application, and the Article 50 transparency duties, took effect on 2 August 2026. Article 50 is the one that catches ordinary business systems: it covers disclosure when a person is interacting with an AI, and the marking of synthetic content.
Deferred, not cancelled. The Digital Omnibus on AI, adopted as Regulation (EU) 2026/1744 and in force from 27 July 2026, pushed the high-risk obligations back: stand-alone high-risk systems under Annex III to 2 December 2027, and high-risk AI embedded in already-regulated products under Annex I to 2 August 2028. These are fixed dates, not conditional ones.
The trap in that deferral. High-risk documentation describes design decisions being made now. Reconstructing it in 2027 from a system already in production costs several times more than recording it as you build. If there's any prospect your system lands in a high-risk category, the cheap moment to start documenting is the moment you start building.
Whether a specific system falls into a high-risk category is a legal question about your use case, not a technical one. We'll build to whatever standard your counsel sets, and we'd rather build to the stricter interpretation from the start than retrofit.
| Fixed scope | Monthly retainer | Embedded team | |
|---|---|---|---|
| Best for | A defined build with clear boundaries | Ongoing development on a system in production | Extending your own engineering team |
| Commitment | Per project | Rolling monthly | Rolling monthly |
| You get | Written scope, fixed price, fixed date | A set capacity each month, reprioritised as you need | Named engineers working in your process and tooling |
| Typical use | Proof of concept, first production build, migration | Evaluation, tuning, new sources, cost work | Long-running AI programmes with in-house leadership |
| Pricing | Scoped and quoted on a call | Sized to your capacity needs | Sized to your team |
Model and infrastructure costs are yours and billed by your provider. We estimate them with you before you commit and we'll tell you when a design decision has a big cost consequence, because at this layer, most of them do.
Most people arriving here have a problem rather than a model requirement. If one of these is yours, the specific page will be more useful than this one.
If you're not sure which, that's a good first call. The layer described on this page is the same underneath all four, so the question is only which application actually solves your problem, and that's usually clear within twenty minutes.
Probably not yet. Fine-tuning changes behaviour and form, not knowledge, if the model needs to know your information, that’s retrieval. The strongest real case for fine-tuning is moving a task you’ve already proven onto a smaller, cheaper model at volume. We’ll tell you if you’re in that position.
Retrieval gives the model access to your information at the moment it answers, and updating it means updating a document. Fine-tuning adjusts how the model behaves, and updating it means retraining. Most business problems are the first kind, and a lot of expensive projects have been the second kind applied to the first problem.
Yes, in your cloud, your region, or on-premise. It’s the right call when data genuinely can’t leave your environment, or when sustained volume makes dedicated inference cheaper than API pricing. We’ll model the crossover honestly, including the costs that don’t appear in a per-token comparison.
No. We use API tiers with training disabled, or self-hosted models where the data never leaves your environment.
A test set built from your real cases, regression tests run before every change, and drift monitoring after launch. If a vendor’s answer to this question is a demo, that’s a warning rather than an answer.
If you serve EU customers, some of it likely does, the Act’s general application and the Article 50 transparency duties took effect on 2 August 2026. Whether your system is high-risk is a legal question about your use case, and the high-risk obligations were deferred to December 2027 and August 2028. We build the logging, documentation, and disclosure the framework expects, and we’d rather over-document from the start than retrofit.
That’s the normal case, not the exception. We build the model layer behind an abstraction so switching is configuration, not a rewrite, and reviewing it is part of the monthly plan. Anyone building a production system on a single hard-coded provider in 2026 is creating work for themselves.
It depends on volume, model choice, and how much context each request carries, and design decisions move it by an order of magnitude in either direction. We estimate it before you commit and flag the choices with big cost consequences.
You do. Model weights where we’ve tuned them, code, prompts, pipelines, and documentation, transferred on final payment. It runs in your accounts.
Yes, and it’s a common way clients start with us. We’d begin with an assessment of what exists, including telling you honestly if the right move is to rebuild rather than continue.
We’re in Ahmedabad, India, and stay available for video calls in your US and UK working hours, not ours. A written update every Friday plus a short Loom walkthrough.
See what the monthly plan actually covers once a model is in production.
Book a technical call. Tell us what you're trying to build and we'll tell you which of the five approaches it actually needs, roughly what it costs to build and to run, and where the hard parts are. If prompting and retrieval solve it, we'll say so rather than proposing something larger.
