LLM development — AI features that survive contact with production

Every company has seen the same demo by now. Someone pastes an API key into a prototype, wires a chat box to a frontier model, and the room applauds. Six weeks later the same feature is in production and it's a different story: answers drifting from the source material, a monthly token bill nobody budgeted, latency spikes whenever the provider has a bad day, and no way to tell whether last Tuesday's prompt tweak made anything better or worse.

The gap between the demo and the product is engineering. That's the part we do.

What LLM development means in our hands

Evals before vibes. Every prompt, retrieval setting, and model choice is scored against an eval set built from your real inputs. Changes run through that suite in CI like any other regression test. "It feels smarter" is not a merge criterion.

Token cost and latency are performance budgets. Same discipline as the Lighthouse budgets on our web builds. Each feature gets a cost-per-request and a p95 latency target before code starts. Model routing does most of the work: a small, cheap model handles the easy majority of calls, and a frontier model handles the ones that actually need it. Caching and prompt design cover much of the rest.

Structured output, not chat wrappers. Most useful LLM features never show a chat bubble. The model's job is to return typed, schema-validated JSON — extract, classify, route, draft — that your existing code can trust. Validation failures retry or fall back deterministically instead of leaking garbage into your database.

What a typical engagement includes

• Discovery pass to find where an LLM genuinely earns its keep (and where a regex or a SQL query is cheaper and more reliable)
• RAG pipeline: chunking strategy, embeddings, hybrid vector + keyword retrieval, reranking, cited answers
• Model-routing layer across Anthropic, OpenAI, and open-weight models, with provider fallbacks so one outage doesn't take the feature down
• Structured output and tool calling with schema validation on every response
• Eval suite built from real historical inputs, wired into CI as a regression gate
• Latency and token-cost instrumentation: per-feature budgets, dashboards, alerts when spend drifts
• Guardrails: prompt-injection resistance, PII handling, graceful refusal and escalation paths
• Handoff: versioned prompts in git, runbooks, and admin visibility so your team can operate it without us

The stack and the approach

• TypeScript end to end — the LLM layer lives in the same Next.js 16 codebase as the rest of your product, not a bolted-on service in a second language (unless your team is Python-native, in which case we meet you there)
• Postgres + pgvector for retrieval — no separate vector database until your corpus actually demands one
• Thin provider SDKs — direct Anthropic and OpenAI clients behind a small routing layer we hand over, not a heavyweight framework you'll be fighting in a year
• Prompts versioned in git — deployed like code, reviewed like code, evaluated like code
• Streaming by default for anything user-facing; perceived latency is a design problem as much as an infrastructure one

If the feature needs a product around it — auth, dashboards, review queues, billing — that's our home turf: see /services/webapps.

What this looks like in practice

Two engagement shapes we see most often:

A grounded assistant over your own content. Documentation, help-centre articles, policies, or a product catalogue goes through a RAG pipeline; the assistant answers with citations back to source, admits when it doesn't know, and escalates to a human. The eval set is built from real questions your team has already answered — so "correct" is defined by you, not by us.

A document-processing pipeline. Unstructured inbound material (applications, invoices, emails, PDFs) gets extracted into typed records with confidence scores. High-confidence rows flow straight into your database; low-confidence rows land in a human review queue. A cheap model does the first pass, and the frontier model is called only where confidence is low.

Pricing

LLM work is scoped to the project. The cost depends on your data, your integrations, and how deep the eval and guardrail work needs to go — pretending otherwise with a tier table would be dishonest. Contact us with a paragraph on what you're trying to build and we'll come back with a scoped, fixed-price quote. Ongoing model upgrades and eval upkeep can ride on a Care Plan afterwards.

Ready to build the real version?

We respond to every brief within four business hours, and the first thing we'll tell you is whether an LLM is the right tool at all — sometimes the honest answer is a webapp and a good search index.

Start an LLM project → — or book a 30-min call