Bespoke AI development for the narrow set of problems no product solves — scoped honestly, built maintainably, and only recommended when buying genuinely will not work.
The recommendation we make least
Custom AI development is expensive to build, expensive to maintain, and very often reproduces something an existing product already does adequately.
It is also the thing businesses ask for most enthusiastically, because building something bespoke sounds like a competitive advantage. Occasionally it is. Usually it is a way to spend six figures arriving at a capability that was available on a subscription.
So the engagement starts by trying to talk you out of it, and a meaningful proportion of custom enquiries end at that stage. That is the correct outcome and the cheapest one available to you.
When it is genuinely right
Three conditions, all of which have to hold.
No product addresses it. The process is specific enough to your business or your industry that the market has not covered it. Not “the products do not fit perfectly” — genuinely not covered.
The value justifies build and maintenance. Not just the build. Custom AI has a recurring cost in model usage, maintenance as models are replaced, and evaluation to confirm quality has not drifted.
AI is the right tool for the task. Requiring judgement or handling genuinely unstructured input. If it is rule-based, process automation is cheaper and more reliable.
The cases that clear all three do exist. High-volume processing of documents in a format specific to an industry. Answering questions across an internal knowledge base too specialised for any general tool. They are a narrow category.
Grounding in your own content
The most common genuinely useful custom application is a system that answers questions using your documents rather than general knowledge, with citations so the answer can be checked.
Worth understanding before starting: the quality of the result depends far more on the state of your content than on the AI. Well-organised, current, non-contradictory documentation produces good answers. A decade of overlapping drafts with three versions of the same policy produces confident answers drawn from the wrong version.
Which means the document preparation is frequently the larger part of the project, and any proposal that does not account for it is understating the work.
Design for the model changing
The models underneath move constantly — deprecated, replaced, and behaving differently between versions in ways that affect output quality.
A system with a specific model baked into it becomes a rebuild. A system where the model is a swappable component behind an interface becomes a configuration change and a re-evaluation.
Alongside that, ongoing evaluation against a fixed test set is what detects quality drift before your users do.
Verification is not optional
Anything built for a task that matters must show its sources, so the person using it can check rather than trust.
A system that produces confident answers with no way to verify them is not a productivity tool, it is a liability with a good interface. This is a design requirement rather than a feature, and it is one of the things we will not build without.
Handover, not dependency
Documented, owned by someone in your business, and maintainable by a developer who is not us.
Bespoke systems that only their author understands are a recurring problem we get called in to inherit, usually after that author has left. We are not interested in creating another one.