AI integration for software that already has users.

The problem is almost never the model

Ask a language model to summarise a document and it works on the first try. That is why proofs of concept are easy and why so many of them never ship. The demo runs once, on data somebody chose, with a person watching. Production runs a thousand times a day on data nobody vetted, with nobody watching, and it has to be right, cheap and fast at the same time.

Everything between those two states is engineering, not prompting. What retrieval does the model need, and how do you know it retrieved the right thing. What happens when it is confidently wrong. What it costs per user per month at ten times the current volume. What you do when the provider deprecates the model in nine months. Those are the questions that decide whether an AI feature ships, and they are the ones a demo never has to answer.

What we build

Five shapes cover most of the work. Real projects mix them, and the scoping call is mostly about working out which mix you need.

Retrieval over your own content

Answering questions from your documentation, your ticket history, your product catalogue or your policies, with citations back to the source. This is the most common request and the one with the most ways to go quietly wrong. It is covered in full further down, under retrieval-augmented generation.

Agents that actually touch your systems

A model given tools — your API, your database, a payment provider, a ticketing system — and the authority to use them in sequence. The interesting engineering is not the loop, it is the blast radius: what the agent is allowed to do without a human, what gets logged, what is reversible, and what happens on the third retry.

Extraction and classification

Turning unstructured input — invoices, emails, CVs, support tickets, contracts — into typed records your existing code can use. Usually the highest return on effort of anything here, because it replaces manual data entry with something measurable, and because a schema gives you a natural way to check the output is right.

Generation inside the product

Drafting, rewriting, summarising and translating, embedded where the user already works rather than in a chat window bolted onto the corner of the screen. Streaming, cancellation and a sane empty state matter more here than model choice.

Evaluation and guardrails for AI you already shipped

Sometimes the feature exists and nobody can tell whether it is getting better or worse. We build the eval suite, the regression harness and the monitoring after the fact, which is less satisfying than building it first but a great deal better than continuing to guess.

Retrieval-augmented generation, in detail

Retrieval is the most requested AI feature and the one that most often ships broken, so it gets its own treatment here rather than a page of its own.

Embedding a folder of PDFs, storing the vectors and asking a model a question over the top three matches is a genuinely small amount of code. It will work on the first question you try, and keep working for about a week — until somebody asks a question whose answer lives in a table on page 40, or spans two documents, or exists in three versions where only the newest is correct. At that point the system is not slightly wrong; it is confidently, fluently wrong, because the generation step did its job perfectly on whatever it was handed. Every hard problem in retrieval is a search problem wearing a generation costume.

Chunking is a decision, not a default

Splitting text every 500 characters with a 50-character overlap is the default in every tutorial. It is a reasonable starting point for prose and actively wrong for most real corpora: a chunk boundary through the middle of a table destroys the table, and a legal clause without its defined terms is worse than no chunk at all.

Vector search alone is not enough

Embeddings are good at meaning and bad at exactness. Ask for error code E-4412, a part number, a surname or a version string, and pure vector search will cheerfully return five semantically similar passages that mention none of them. Keyword search finds those instantly and is hopeless at paraphrase, so we run both.

1. 01Retrieve twice. BM25 keyword search and vector search, run in parallel, each returning its own candidates.
2. 02Fuse the results, usually with reciprocal rank fusion — cheap, robust, and it needs no tuning per corpus.
3. 03Re-rank the fused set with a cross-encoder, which reads the query and each candidate together rather than comparing two independent embeddings. This is usually the single biggest accuracy gain in the whole pipeline.
4. 04Then generate, over a small number of high-confidence passages rather than a large number of mediocre ones.

Permissions are stored as metadata on each chunk, mirrored from the source system rather than re-implemented, and the index is re-synced when access changes — so revoking someone's access to a folder actually revokes it in search. Retrieval is scored separately from generation, on recall@k against a set of real questions, because if the right passage was never found then no amount of prompt rewriting recovers it. How to add RAG to an existing SaaS product is the practical walkthrough, and RAG versus fine-tuning covers when retrieval is the wrong tool entirely.

How we pick a model

Model choice is a cost and latency decision far more often than a capability one. The frontier models are all good enough for most product work; what separates them in practice is price per token, time to first token, context window, and whether the provider will still serve that exact version in a year.

We are not tied to a provider. Most of what we ship runs on Anthropic's Claude or OpenAI's models, some of it on open-weight models where the data can't leave, and plenty of it on a mix — routing the cheap high-volume calls to a small model and reserving the expensive one for the cases that need it.

Evals are the deliverable, not the demo

Nobody asks for evals. They ask for the feature, and then six weeks later somebody changes a prompt, something else gets worse, and there is no way to tell. We build the eval suite as part of the feature, not as a follow-up, because the alternative is a system nobody is allowed to touch.

• A graded test set built from your real data, not synthetic examples — usually 50 to 200 cases, which is enough to catch regressions and small enough to stay maintained.
• Task-appropriate scoring. Exact match where there is one right answer, retrieval metrics for RAG, and model-graded rubrics where the output is prose. We will tell you which of these is actually trustworthy for your case.
• A regression gate in CI, so a prompt change that drops accuracy four points fails before it reaches users rather than after.
• Production sampling, because the test set ages. A slice of real traffic gets scored continuously and feeds back into the set.

This is covered in more depth in the evals and guardrails we build before shipping an LLM feature.

Guardrails, and what they actually stop

Guardrails are usually discussed as a safety topic. In product work they are mostly a correctness and cost topic, and the honest framing is that they reduce risk rather than eliminate it.

• Prompt injection. Any system where the model reads untrusted text — a web page, a user's uploaded file, an inbound email — can have its instructions overwritten by that text. The mitigation is architectural: least privilege on tools, no irreversible action without confirmation, and never trusting model output as a command.
• Output validation. Structured output parsed against a schema, and a defined path for what happens when it doesn't parse. A retry, a fallback, or an honest error — decided deliberately, not left to whatever the code happens to do.
• Cost and rate limits per user and per tenant, so one enthusiastic customer or one retry loop cannot produce a five-figure invoice.
• PII handling. What gets sent to a third-party provider, what gets redacted first, what gets logged, and how long any of it is retained.
• Graceful degradation. When the provider is down or slow, the feature degrades to something useful instead of the page hanging.

What it costs to run, not just to build

The build price is the part everyone asks about and the smaller number over three years. An AI feature has a running cost that scales with usage, and it is worth modelling before you launch rather than discovering it on an invoice.

We build a cost model during scoping: expected calls per user, tokens per call, cache hit rate, and what all of that becomes at your current volume and at ten times it. It is an estimate, and we say so, but an estimate with the working shown beats a surprise. What it actually costs to build an AI feature walks through the same arithmetic.

40–80%

Typical token cost cut by prompt caching

10–30×

Price gap between small and frontier models

3 years

Horizon we model running costs over

And then somebody has to own it

An AI feature is not a static thing you install. Models get deprecated, providers change pricing, your data drifts, and the eval suite that passed in March starts failing in September because the world moved. Most studios hand over a repository and disappear at exactly this point.

We stay. That is the actual differentiator, and it is why our retainers are a named service with published prices rather than something we improvise after the invoice clears.

What you get

Everything below is in the price.

Stack

The specific things we build with.

FAQ

Questions people actually ask

Keep reading

Related work and reading