AI & Automation
Custom AI Development
RAG, copilots and AI products built to hold up
- Retrieval that returns the right passage, measured
- Guardrails, audit trails and PII handling built in
- Ships as a maintainable codebase you own
- 8-10 weeks
- Demo to production
- 3x
- Retrieval precision after tuning
- 100%
- Code and IP handed over
Pilot to Production engagement
Versus a naive vector-search baseline
No vendor lock, no black boxes
The gap between a demo and a product
A convincing AI demo takes a good engineer about a week. A version that 500 people use daily takes considerably longer, and almost all of the extra work is unglamorous: retrieval quality, evaluation, error handling, cost control, auditability, and the long tail of inputs nobody anticipated.
Demo
- Answers are impressive in the demo corpus, wrong at real scale
- Nobody can say whether a prompt change made things better
- Inference spend is a surprise on the monthly bill
- One provider outage takes the feature offline
- Prompt injection is an unexamined risk
Production
- Retrieval precision tracked against a labelled query set
- Every change scored by the evaluation suite in CI
- Cost per request budgeted, alerted and attributed per feature
- Provider abstraction with automatic fallback
- Injection and PII defences with an audit trail
What we build most often
Knowledge assistants over policy libraries, technical documentation, contracts and historic tickets — with citations, so answers can be checked.
Customer-facing AI features inside an existing product: drafting, summarising, classifying, matching. Built with the latency and cost budget of a product feature, not a research prototype.
Internal copilots that read your systems and take action in them, scoped by the signed-in user's real permissions.
Structured extraction services turning unstructured input into validated, typed records your downstream systems can trust.
How we work
We write normal software. Typed, tested, reviewed, deployed by CI, observable in production, and readable by whoever inherits it. The AI parts are components inside that, not an exception to it.
You own the code and the IP from the first commit. If you decide to take it in-house, or hand it to another partner, nothing about our architecture makes that painful — which is the only real proof that a build was done for your benefit rather than ours.
How it runs
What the engagement looks like
Phases, not a proposal. Each one has an output you can see.
- 1
Define task success before architecture
Week 1We write down what a correct answer looks like and how it will be scored. Skipping this is why so many AI projects cannot tell whether they are finished.
- 2
Build the retrieval spine
Weeks 2-4Chunking strategy, hybrid keyword-plus-vector search, reranking and metadata filters, tuned against a labelled query set. Most "the model is bad" complaints are retrieval problems.
- 3
Layer the application
Weeks 4-7Streaming UI, tool calling into your systems, session handling, citations. Built as normal software with tests, not as a notebook that someone deploys.
- 4
Harden and instrument
Weeks 7-9Injection defences, rate limits, audit logging, cost caps and graceful degradation when a provider has a bad afternoon.
- 5
Transfer ownership
Week 10Your engineers get a walkthrough, the runbook and the evaluation suite. We are available afterwards, but you are not dependent on us.
Proof
Where we have done this
Mobile network operator
Recovering more from overdue accounts by contacting fewer of them
An operator chased every overdue account with the same reminder cadence and the same escalation, spending heavily on balances that would never be recovered, offering settlements to customers who would have paid in full, and pushing customers in genuine difficulty through a sequence designed for someone else.
- 23%
- Recovery uplift on aged balances
- 31%
- Fewer contacts per rupee recovered
- 100%
- Recommendations with a recorded reason
B2B SaaS platform
Shipping a stalled AI feature in nine weeks
A Series-B SaaS company had an AI summarisation feature that demoed well for seven months but could not ship — nobody could state its accuracy, its cost per user, or what happened when the model provider had an outage.
- 9 weeks
- Prototype to general availability
- 47%
- Inference cost reduction
- 0
- Provider outages visible to customers
FAQ
Questions we get asked
Which model do you use?
Whichever fits the task, cost and residency constraints — and often more than one in the same product. We default to Claude for reasoning-heavy work and route simpler steps to smaller, cheaper models. The architecture keeps the provider swappable, because pricing and capability move every few months.
Can this run entirely inside our environment?
Yes. We deploy into your cloud account, and for workloads that cannot leave your network we design around self-hosted open-weight models. Expect a capability trade-off, which we will quantify before you commit.
Why does retrieval need this much work?
Because the answer quality is capped by what you retrieve. Naive chunking plus cosine similarity works in a demo with 50 documents and fails at 50,000. Hybrid search, reranking and metadata filters are the difference.
What do we do about hallucinations?
Constrain the task, ground every claim in retrieved context, cite sources so a user can verify, and refuse rather than guess when confidence is low. Measured on the evaluation suite, not asserted.
Talk to someone who does custom ai development
Thirty minutes with an engineer who has delivered this, not an account manager. You will get a straight answer on feasibility, rough cost and where it would fail.
Or email [email protected] · we reply within 1 business day