AI & Data
AI that survives
contact with production
We build AI systems that hold up under real traffic, real data drift and real auditors. That means evaluation harnesses before model selection, fallback paths for every inference call, and a cost ceiling agreed before the first line of code.
Overview
Applied AI systems built to run in production, not to demo well.
Most enterprise AI work fails at the seams rather than the model. The data contract changes, the vendor deprecates an endpoint, the latency budget doubles at quarter-end, and nobody owns the rollback. Our AI development practice starts from those seams: interfaces, evaluation, observability and cost, then the model that fits inside them.
Work splits three ways. Discovery decides whether the problem needs a model at all — a fair share of requests are better served by a rules engine or a query. Build covers data pipelines, training or prompt orchestration, and the serving layer. Run covers drift monitoring, retraining triggers, and the on-call runbook your team inherits.
We work in your cloud account, under your IAM policy. Model weights, embeddings and inference logs stay inside your VPC unless you decide otherwise in writing — which matters when a regulator asks where the training data went, and it will. Engagements run in eight-week blocks with a demonstrable system at each boundary.
- 340ms
- p95 inference latency for a 7B model served on A10G GPUs
- 62%
- Manual review queue reduction at Kestrel Industrial over 9 months
- £0.0041
- Median cost per inference after quantisation and response caching
Capabilities
What this covers
Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.
Feasibility and baseline modelling
Before any build, we set a non-AI baseline and measure against it. If a SQL query and a lookup table get within four points of the model, we tell you and stop there.
Model selection and evaluation harnesses
A held-out evaluation set built from your own records, scored on the metric your business actually pays for. Regression suites run on every prompt or weight change, so quality moves are visible before release.
Inference serving and latency budgets
We design against a stated p95 latency and a per-request cost ceiling. That usually means batching, quantised models on GPU or ONNX Runtime on CPU, and a cheaper fallback model wired in behind a circuit breaker.
Human-in-the-loop workflows
Confidence thresholds route uncertain cases to a reviewer queue rather than to the customer. Reviewer decisions feed back as labelled data, so review load falls over time instead of becoming permanent headcount.
AI governance and audit trails
Every inference logged with model version, prompt hash, input reference and decision, retained to your policy. Enough to reconstruct a single decision two years later when someone disputes it.
Production hardening and handover
Load tests at three times expected peak, failure injection on the model endpoint, and a runbook your engineers rehearse with us. We leave when your team has shipped a change without us in the room.
Deliverables
What you get
- Feasibility report with baseline benchmark and go / no-go recommendation
- Evaluation harness and versioned held-out dataset in your repository
- Production inference service with autoscaling, circuit breakers and cost alerts
- Model card, data lineage record and audit log schema
- Drift monitoring dashboards with alert thresholds and escalation paths
- On-call runbook plus two rehearsed handover sessions with your engineers
Stack
What we build it with
- PyTorch
- Hugging Face Transformers
- ONNX Runtime
- Ray
- MLflow
- NVIDIA Triton Inference Server
- Weights & Biases
- Amazon SageMaker
- Kubernetes
- Apache Airflow
- FastAPI
- Terraform
Process
How the engagement runs
Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.
Problem framing
Two weeks with your operators and data owners to define the decision being automated, the cost of a wrong answer, and the baseline that has to be beaten.
Data readiness review
We profile the actual tables, not the schema diagram. Missing values, label noise and leakage get documented before anyone trains anything.
Baseline and prototype
A working prototype scored against the baseline on your evaluation set. If it does not clear the bar, we say so and the engagement stops here.
Production build
Serving layer, monitoring, access control and cost controls, built in your cloud with your CI pipeline and reviewed by your engineers as we go.
Run and handover
Six to twelve weeks of joint operation, then handover: runbooks, rehearsed incident drills, and a retraining schedule your team owns outright.
When this is the wrong engagement
If you need every decision explained line by line to a regulator with no statistical uncertainty attached, a deterministic rules engine is the right build and we will say so in week one.
FAQ
Questions we get asked
- Do we need a data science team to work with you?
No, but you need a data owner who can answer questions about how records are created and who can approve access. We have delivered without an in-house data scientist several times; the projects that stall are the ones where nobody can explain what a field means.
- How do you price AI work when the outcome is uncertain?
Discovery and feasibility are fixed-price, typically three to five weeks. Build phases are time and materials against a capped estimate per eight-week block, with a documented exit at each boundary. We do not quote a fixed price for model accuracy, because nobody honestly can.
- Will our data be used to train someone else's model?
No. Training and fine-tuning run in your cloud account on your data, and where a hosted API is involved we configure zero-retention endpoints and record the contract terms in the model card. Any exception needs written sign-off from your side before it ships.
- What if a general-purpose model gets close enough without custom work?
Then we use it and bill less. Roughly a third of the problems brought to us are solved by a well-structured prompt over an existing API plus retrieval, and a custom model would add cost and maintenance for two or three accuracy points nobody would notice.
Related
More in AI & Data
AI & Data
Generative AI
Generative systems with measured output quality and a bill you can predict.
AI & Data
Machine Learning
Forecasting, ranking and detection models that keep working after the data shifts.
AI & Data
LLM Integration
Wiring language models into systems that already have owners, SLAs and auditors.

