Keys and calls in every service
Each team wires up its own provider client, with its own retries, timeouts and secrets. Rotating a key or changing a model means hunting through every repository.
LLM integration
LLM Integration and Fine-Tuning for Your Existing Stack
Language models added to the software you already run — your codebase, your authentication, your data stores, your deployment pipeline. We put GPT, Claude, Gemini or open models behind a single gateway your services call, so prompts are versioned, spend is visible, providers can be swapped, and fine-tuning happens only when the numbers justify it.
- One gateway in front of every model
- Swap providers without rewriting features
- Fine-tuning only after a measured gap
Why integrations get messy
The second LLM feature is where it goes wrong.
The first model call usually goes straight into a controller. By the third feature there are API keys in several services, prompts pasted into string literals, no shared logging, and nobody can say what the whole thing costs.
What a clean integration gives you
Treat the model as one more dependency, behind an interface your own code controls:
- One place for keys, limits, retries and fallbacks
- Prompts versioned and released like code
- Cost and latency visible per feature and per customer
- A provider change as a configuration and test run, not a rewrite
- Open models in your own cloud when data must stay put
Prompts nobody can trace
Instructions live in code strings and admin panels. When output changes, there is no record of which prompt version or model produced it, so problems cannot be reproduced.
Tied to one provider
Code written against one vendor’s SDK and response format makes a price rise, an outage or a better model elsewhere expensive to act on.
Spend with no owner
Usage arrives as one invoice with no split by feature or customer. Finance sees the total rise and engineering cannot say which release caused it.
Integration work
What we add to your stack.
Most of the work is ordinary software engineering around the model call — the parts that decide whether your own team can maintain it once we step back.
Model selection on your data
Shortlisted models compared on your own examples for quality, speed, cost and data terms, with the result written up so the choice can be revisited later.
LLM development in the UK
An LLM gateway layer
A thin internal service or library every feature calls: provider adapters, authentication, rate limits, retries, timeouts, fallbacks and logging in one place.
Discuss this
Prompt registry and releases
Prompts stored as versioned templates with tests, released through your pipeline, and every response tagged with the prompt and model that produced it.
Discuss this
Evals on every pull request
Test sets drawn from real traffic and scored automatically in CI, so a prompt edit or model upgrade is judged on evidence rather than a spot check.
Discuss this
Open models in your cloud
Llama, Mistral or other open models deployed in your AWS, Azure or Google Cloud account — in a UK region if required — behind the same gateway as hosted models.
Cloud services
Fine-tuning, when it pays
Training data preparation, tuning runs and a side-by-side comparison with the untuned model, recommended only where prompting and retrieval leave a measured gap.
Discuss this
How we work
How we integrate models into live systems.
The standard seven stages, adapted for adding a dependency to software that is already in production: small changes, behind flags, with a way back.
- 01
Discovery
We read the relevant code, trace where model calls already exist or will sit, and gather real inputs and expected outputs for the features in scope.
An integration map and first test set
- 02
Strategy
Gateway design, provider shortlist, hosted or self-hosted route, and a per-feature budget for latency and cost, each recorded as a decision your engineers can review.
Architecture decisions and a quote
- 03
UX & architecture
Where model output reaches users, we design streaming, loading and failure states, and decide what the product does when a model is slow or unavailable.
Fallback behaviour users can live with
- 04
Development
Two-week sprints in your repositories, following your conventions and code review. Existing model calls move behind the gateway one at a time.
Features running through the gateway
- 05
Testing
Evaluation runs on every pull request, failure drills for provider timeouts and outages, and load tests against the agreed latency budget.
An evaluation and resilience report
- 06
Launch
Traffic shifted gradually behind feature flags, with spend, latency and error rates per feature on a dashboard before the rollout widens.
A gradual, reversible cut-over
- 07
Optimisation & support
When a provider changes prices or releases a new model, we run your evaluation set against it and switch by configuration if it wins.
Provider switches tested before rollout
Technology
Providers, runtimes and plumbing.
We work in the languages and platforms you already use, and keep provider-specific code at the edges so it can be replaced without touching features.
Hosted providers
OpenAIAnthropic ClaudeGoogle GeminiCloud model platforms
Open model serving
Llama and MistralvLLM and similar serversGPU instances in your cloudQuantised models for smaller hardware
Gateway
Provider adaptersRate limits and retriesFallback routingSecrets management
Your languages
PythonTypeScript and Node.jsC# and .NETJava and Go
Fine-tuning
Hosted fine-tuning APIsLoRA adapters on open modelsTraining data preparationTuned versus base comparisons
Observability
Request tracingToken and cost meteringEvaluation runs in CILatency and error dashboards
Provider features, prices and model versions change often. We check current terms and availability for your shortlist during design, rather than relying on what was true a few months ago.
Use cases
Integration jobs we are asked to do.
Most engagements start with software that already exists and a model that needs to fit into it properly.
Consolidating scattered model calls
Move model calls from several services behind one gateway, with shared logging, limits and a single view of spend.
Switching or adding a provider
Test an alternative model on your evaluation set and move traffic across by configuration, keeping the old provider as a fallback.
Self-hosting an open model
Run an open model in your own cloud account so sensitive data never goes to a third-party API, behind the interface your features already call.
Tuning a small classifier
Replace a large general model on a narrow, repetitive task with a smaller tuned one, where tests show it matches quality at lower cost and latency.
Evals for a feature already live
Build a test set from production traffic for a feature that shipped without one, so future prompt and model changes stop being guesswork.
Model features for legacy apps
Expose model features to older .NET, Java or PHP applications through a clean internal API, without rewriting the application around them.
Why Techsleight
What working with us is actually like.
No inflated numbers — just how we run projects, and what you can hold us to.
Product engineering, not ticket-taking
We ask what the software is for before we estimate it — and we will tell you when something should not be built, or should be bought instead.
AI where it earns its place
LLM features, retrieval and automation built with evaluation, guardrails and cost controls, and plain software where that is the better answer.
Full-stack under one roof
Design, frontend, backend, mobile, cloud and QA in one team, so nothing falls between suppliers.
UK-focused delivery
UK business hours, estimates in pounds, and a contract with a UK company. Our engineers are based in the UK and India.
Flexible engagement
A fixed-scope project, dedicated developers or a monthly retainer — and you can move between them as the work changes.
You own everything
Code, IP, cloud accounts and documentation are yours from day one. We sign an NDA before discovery if you need one.
Support after launch
We stay on for fixes, upgrades and new features, or hand over cleanly to your in-house team with the documentation to match.
FAQs
Questions we get asked.
Straight answers on scope, cost, timelines and how we work. If yours is not here, ask us directly.
Should we call the model provider directly or build a gateway?
For one experimental feature, calling the provider directly is fine. Once two or more features or services use models, a thin gateway pays for itself: one place for keys, retries, fallbacks, logging and cost tracking, and the freedom to change provider without touching feature code. It can be a small shared library rather than a new service.
How hard is it to move from one LLM provider to another?
Harder than it looks when code depends on one provider’s SDK and response shapes, and prompts have been tuned to one model. Behind a gateway with an evaluation set, it becomes a test run: point the gateway at the new model, compare quality, cost and latency, adjust prompts where scores drop, and shift traffic gradually.
What does a fine-tuning project actually involve?
Collecting and cleaning a set of examples of the exact input and output you want — typically hundreds to thousands — running tuning jobs, and comparing the tuned model with both the base model and a well-prompted larger one on held-out test data. The work has to be repeated when the base model is retired, so we include that maintenance in the estimate.
Can you fine-tune an open model and host it for us?
Yes. Open models such as Llama or Mistral can be tuned with lightweight adapter methods and served from GPU instances in your own cloud account, including in a UK region. You own the weights and the infrastructure; the trade-off is that you also run it, so we set up monitoring and scaling and document how to operate it.
Will integrating an LLM slow our application down?
Model calls take longer than most API calls, so we keep them off the critical path where we can: streaming for user-facing text, background jobs for bulk work, caching for repeated requests, timeouts with sensible fallbacks, and smaller models for simple steps. Each feature gets a latency budget that is tested before launch.
Can you track LLM spend per feature or per customer?
Yes. The gateway tags each request with the feature and customer or tenant, and records the model, tokens and price. That feeds a dashboard and alerts, so you can see cost per task, set limits per customer, and reflect usage in your own pricing if you want to.
What happens when a provider retires the model we use?
Providers publish deprecation schedules, and pinned model versions do eventually stop working. With a gateway and an evaluation set, the replacement is tested well in advance, prompts are adjusted where scores drop, and traffic moves before the deadline rather than on it.
Do you work in our codebase or deliver a separate service?
Usually in your codebase, following your conventions, code review and CI, so your engineers own the result. Where a separate service is the cleaner design — a gateway shared by several teams, for example — we build it in your cloud account and document it for handover.
What does LLM integration cost?
A discovery sprint from £2,000 maps the integration and ends in a fixed quote for the build. Ongoing work can be a dedicated developer from £2,900 a month or flexible hours from £20 an hour. Model and API usage, and GPU hosting for self-hosted models, are separate costs paid directly to the provider.
Who carries out the integration work?
Onshore and offshore engineers who work in Python, TypeScript, C#/.NET and Java, collaborating remotely on UK business hours through a shared channel, weekly written updates and fortnightly demos. For choosing a UK LLM partner more broadly, see our LLM development in the UK page.
Start a project
Adding models to an existing product?
Tell us about your stack, the features that use or will use a model, and what is not working today. An engineer will reply with questions and a suggested first step.
What happens next
- 1A senior engineer reads your brief within one working day, and replies with questions or a first view.
- 2A 30-minute call to understand the goal, constraints and what good looks like — no sales script.
- 3A written proposal with scope, milestones, team and a GBP estimate you can take to your board.
Techsleight Labs is a trading name of Krapton IT Consultancy.
Explore