// AI and automation
AI that survivescontact with users
The part most agencies subcontract. Retrieval pipelines, model features inside products that already exist, generative image, video and voice work, and automation that runs unattended.
Timeline
4 to 10 weeks
You get
Pipeline, evals, cost model
Scope
Fixed after discovery
Ownership
Your repo and your keys
An AI demo takes an afternoon. An AI feature that a customer relies on takes the rest of the project, and almost all of that time goes on the cases where the model is confidently wrong.
Every build here ships with an evaluation set and a cost per request, because those are the two numbers that decide whether a feature can stay switched on.
What the work covers
Retrieval and document intelligence
RAG pipelines over your own content: chunking, embedding, retrieval, reranking, and citations a reader can click to check the answer.
LLM features inside existing products
Adding a model to software that already works, without the rest of it becoming non-deterministic. The model requests, the server validates and executes.
Generative image, video and voice pipelines
Production pipelines rather than one-off prompts. Queued, versioned, reproducible, with the output reviewable before it reaches anyone.
Agents and workflow automation
Automation with a defined boundary, an audit trail, and a human in the loop wherever the action is hard to reverse.
Evaluations and regression tests
A scored set of real cases, run on every prompt or model change. Without it, a prompt edit is a change with unknown consequences.
Cost modelling and rate control
Token cost per request measured, budgeted and capped, so a feature cannot quietly become the largest line on the invoice.
What goes wrong with AI projects
Not a list of things other people do badly. These are the ones worth checking before anybody quotes you.
- 01The demo is the product. It works on the five inputs it was built with, and the sixth is a support ticket. An evaluation set is the difference.
- 02The model is trusted to report its own success. It will say a booking was made when no booking was made. The server has to validate and execute, and the model reads its own failure.
- 03No cost ceiling. Usage is fine in the pilot and unaffordable at scale, and nobody measured cost per request until the bill arrived.
- 04Retrieval nobody checked. If the wrong passages come back the answer is wrong no matter which model reads them, and most retrieval quality problems are chunking problems.
- 05A token ceiling set too low. Reasoning models spend output tokens on hidden reasoning before writing a visible word, so the reply truncates mid-sentence while the call still reports success.
- 06Prompts edited directly in production with no version and no test, which makes every regression impossible to attribute.
Questions we get asked
Whichever fits the problem and the budget, and we will tell you why. Model choice is a decision with a cost attached, not a preference, and it gets revisited when the pricing or the capability moves.
Often paired with
Your next product starts here.
Tell us what you're building, right here. Attach a brief if you have one — no commitment, no pressure, just a real reply.