Skip to main content
Fugen Services logo

AI & Automation

Add AI to the product you already have, without destabilising it

You already have a product, and there is an obvious place AI belongs in it: summarising a long record, drafting a first reply, extracting structure from what a user typed, answering from your own documentation. The feature is usually a week of work. Making it cheap, fast, safe and not dependent on one vendor is the rest of it.

Indicative

From £6,000

Fixed price agreed in writing before any build starts.

Get a quote+44 7488 265083

The problem this solves

The naive integration is a direct API call in a request handler. It is slow, so the UI hangs. It has no cost ceiling, so an unusual month produces an unpleasant invoice. It has no fallback, so the provider’s outage is your outage. And it is coupled to one vendor’s SDK, so switching means a rewrite.

What you get

A provider-agnostic layer

One internal interface with adapters behind it, so changing model or vendor is configuration. In a field where the price-performance leader changes every few months, this pays for itself quickly.

Streaming responses

Tokens streamed to the interface as they arrive. A ten-second wait with a spinner feels broken; the same ten seconds with text appearing does not.

Cost controls that actually bind

Per-user and per-tenant quotas, token caps per request, and spend alerting. Enforced in your code, not left to the provider’s dashboard, so a runaway loop cannot produce a four-figure surprise.

Caching where it is safe

Identical prompts served from cache, and prompt caching used where the provider supports it. On repetitive workloads this often cuts cost by more than half.

Structured output, validated

Where the feature needs JSON, the schema is enforced and validated before use, with a retry on mismatch. Parsing a model’s prose with a regular expression is how these features break in production.

An evaluation set

Twenty to fifty real inputs with expected outputs, run on every prompt and model change. Without it, "improving the prompt" is guesswork and regressions ship silently.

How we work

  1. Pick the right feature

    Where an LLM adds real value and a wrong answer is recoverable. We will argue against the ones that are neither.

  2. Prototype and benchmark

    Two or three model and prompt combinations measured on your real inputs for quality, latency and cost per call.

  3. Build the abstraction

    Provider adapter, streaming, retries, timeouts, quotas and caching.

  4. Wire into the product

    The feature itself, with loading, error and empty states that behave sensibly.

  5. Evaluate and tune

    Prompts iterated against the evaluation set until quality and cost both land.

  6. Ship behind a flag

    Released to a subset of users, with usage and cost watched before it goes to everyone.

What you should expect

  • An AI feature in production without slowing the rest of the product
  • A per-tenant cost ceiling that cannot be exceeded
  • Provider switchable by configuration rather than by rewrite
  • Prompt changes measured instead of guessed at

Built with

  • Mistral
  • OpenAI
  • Anthropic Claude
  • Vercel AI SDK
  • TypeScript
  • Node.js
  • Python
  • PostgreSQL
  • pgvector
  • Redis
  • Next.js
  • Server-Sent Events

Mainstream, well-supported technology — chosen so you can hire for it and so another team could take the project over.

LLM Integration — your questions

Including the ones about cost, which most agencies leave off the page.

A single well-scoped feature in an existing codebase typically runs £6,000 to £15,000, including the abstraction layer, cost controls and evaluation set. The model usage itself is usually a small monthly figure — the engineering is the cost.

Whichever wins on your evaluation set, which is often not the most expensive one. A well-prompted mid-tier model frequently matches a frontier model on a narrow task at a fraction of the cost. That is exactly what the benchmarking step is for, and why the adapter matters.

The integration is built with a timeout, a retry, and a fallback to a second provider where the feature warrants it. Where there is no sensible fallback, the feature degrades visibly — a clear "unavailable, try again" — rather than hanging or throwing a 500.

Token caps per request, quotas per user and per tenant, caching of repeated prompts, and spend alerts. All enforced in your application, because a provider dashboard tells you about the problem after it has happened.

Not on the API tiers we use, and we confirm the specific terms in writing for your chosen provider. If your customers need a contractual guarantee, that is a procurement question we help you document properly — and it is worth resolving before you ship, not after a customer asks.

Yes, that is the normal case for this service. We follow the conventions already in the code rather than introducing a parallel style, and the integration goes in behind a feature flag so it can be turned off without a deploy.

Talk to someone who has built this before

A short call is usually enough to tell you whether this is the right service for your situation — including when it is not.