Discovery and feasibility
What you are actually trying to do, whether the data supports it, what it would take, and what it would be worth. Delivered as a written recommendation.
Custom AI Solutions
For the problem nobody sells a product for.
Sometimes the thing you need does not exist off the shelf, because it depends on your data, your rules and the way your industry actually works. We take those from a question to a working system — and we will tell you early if the honest answer is that AI is the wrong tool.
- Feasibility first
- Your data
- Built to hand over
An honest answer first
Feasibility work ends in a recommendation, including the one where we say not to build it.
The idea
Start with whether it can work at all
Custom AI projects fail at the beginning, not the end — on data that turns out not to exist, a success criterion nobody agreed, or a problem that a database query would have solved for a fraction of the cost. So the first piece of work is always the cheapest one: finding out.
- A written problem statement with a measurable definition of success
- An honest look at the data — what exists, what is usable, what is missing
- A prototype on real data before anything is committed to
- A recommendation you can act on, including 'do not build this'
What we build
From feasibility to something in production
Take the whole path or the part you need. Plenty of clients stop after discovery, which is a legitimate outcome.
Data assessment
What you hold, what condition it is in, what is missing and what you are allowed to use it for — the question that ends more AI projects than any modelling problem.
Prototypes
A working version on your real data, quickly, so the decision to invest is made by looking at output rather than at a proposal.
Production builds
The full system, built to the same standard as the rest of our engineering work: tested, monitored, documented and possible for somebody else to maintain.
Evaluation
A test set and a scoring method agreed before the build, so 'is it good enough' has an answer and improvements can be proven rather than claimed.
Governance and handover
Access controls, audit trails, documented limitations, and training for whoever owns it after we leave.
How the work runs
Four stages, in order
Each one ends with something you can look at and a decision you can make — including the decision to stop.
- 01
Define
The problem, the users, the measurable definition of success, and the constraints — regulatory, commercial and technical.
- 02
Prove
A prototype on real data against that definition of success. If it cannot be met, this is where you find out, at the cheapest point.
- 03
Build
The production system, with evaluation running throughout rather than as a phase at the end.
- 04
Operate or hand over
We run it under an agreed arrangement, or hand it to your team with the documentation and training to own it properly.
Built with
Chosen per problem, not per fashion
A custom project is the one place where the choice of approach genuinely varies — and where the cheapest workable option is often not the most interesting one.
Approaches
- Retrieval
- Fine-tuning
- Classical ML
- Rules & heuristics
Models
- Claude
- GPT
- Gemini
- Open-weight models
Engineering
- Python
- Node.js
- PostgreSQL
- Vector databases
Around it
- Eval harnesses
- Monitoring
- Audit trails
- Documentation
Questions
Custom AI solutions, answered
That is what discovery is for, and it is deliberately the smallest piece of work in the project. It ends with a written recommendation — sometimes that the idea works, sometimes that the data will not support it, sometimes that something far simpler would do.
Less of a barrier than it used to be. Approaches that lean on a general model plus your own documents need far less than training something from scratch. The assessment tells you which category you are in.
Yes, and it happens. A recommendation that only ever points at a larger project is a sales document, not advice.
You do — the code, the models trained on your data, and the documentation. We will say clearly which third-party components carry their own licence terms.
Discovery is a fixed, small engagement. What follows is scoped once we know what is actually being built, because pricing a production AI system before the feasibility answer is guesswork on both sides.
The threshold is agreed before the build, so this is a measurable outcome rather than a dispute. If a prototype cannot reach it, the project stops there — which is exactly why the prototype comes first.