Services / AI / Custom AI features

AI inside your product, not bolted onto the side

A recommendation that gets it right. A search that understands what the customer meant. A photograph graded the moment it is uploaded. Features your users experience as your product being better, not as an announcement that you have added AI.

Start the conversation →See the technology

Why it matters

The cost is the wait

There is a real difference between using AI inside your business and building it into what you sell. The first gives you back hours. The second changes what your product can do, and it is the harder one for a competitor to copy, because it rests on your data, your customers' behaviour and your domain's rules rather than on an API that anybody can call.

The features that actually work tend to be unglamorous and very specific: search that finds the thing when the customer describes it badly, a recommendation that lifts basket size, a photograph checked and categorised on upload, a free-text field that quietly becomes structured data. Each removes a step the user used to do by hand, and none of them need the letters A and I attached to be valuable.

We build them the way we build the rest of your product: behind a clear internal interface, with the model as a swappable part, with latency budget and cost per request treated as requirements rather than as surprises after launch, and with a defined fallback for when the model is slow, wrong or unavailable, because a feature that dies when somebody else's platform has a bad afternoon is not really a feature.

What you actually get

Built to be trusted

Building AI into a product is mostly ordinary engineering discipline applied to an unusual component: one that is probabilistic, occasionally slow, and billed by the use.

Fast enough to feel native

A recommendation that arrives after four seconds is not a feature. We design to a latency budget using caching, pre-computation and smaller models, and where a genuinely fast answer is impossible, we design the interface around the wait honestly instead of pretending it is not happening.

Cost per request is a design constraint

Every feature gets a modelled cost per user and per month before it is built. Cheap models handle the easy majority, expensive ones are used only where they change the answer, otherwise a successful launch turns into an unpleasant invoice at the end of the quarter.

It degrades instead of breaking

When the model is slow, rate-limited or down, the feature falls back, to a cached result, a simpler algorithm, or a clearly labelled absence. Your product keeps working on the day a provider does not.

The model is a replaceable part

It sits behind an internal interface, with an evaluation set any candidate model must pass. When something cheaper or better appears (and it will, repeatedly), swapping it is a configuration change and a test run rather than a rewrite of your product.

Measured against real outcomes

Not "the model scored well" but did the recommendation get clicked, did the search end in a purchase, did the support tickets fall. Shipped behind a flag and compared against your existing behaviour, because a plausible-sounding feature that changes nothing is worse than no feature at all.

Built on data you are allowed to use

Before anything is trained or indexed we check what your terms, your customer contracts and your users' consent actually permit, and design within it. Retrofitting that after launch is expensive; discovering it during an enterprise customer's security review is worse.

Where it earns its keep

Same pattern, different desks

The common thread is a step your customers currently do by hand inside your product: describing, categorising, choosing, searching.

01 · Marketplaces & classifieds

Listings that write themselves from a photograph

The problem: Sellers abandon listings halfway through, because writing a title, picking a category and filling in attributes is tedious on a phone. The listings that do get finished are wildly inconsistent, which makes search and filtering worse for buyers, and a marketplace lives or dies on whether buyers find things.
What we build: Photographs are read on upload to suggest a category, a title, a condition and the attributes that category needs, all editable before publishing. On the buying side, search that matches meaning as well as keywords, so a plain-English description finds the right listings even when the seller described the item differently.
What changes: More listings completed, far better structured data sitting behind them, and search that works on the badly written listings, which are the majority on any marketplace, including yours.

02 · B2B SaaS platforms

The feature your customers keep asking for

The problem: Your users spend part of every day inside your product doing something repetitive (categorising transactions, writing summaries, triaging inbound items) and they have started asking why the software cannot do it for them. Meanwhile a competitor's release notes have begun mentioning AI.
What we build: One well-chosen feature built properly into the product: grounded in each customer's own data with strict tenant isolation, priced so it does not quietly erode your margin, measured against whether it changes user behaviour, and shipped behind a flag to a subset of accounts first.
What changes: A feature that comes up in renewal conversations rather than only in a press release, plus an internal pattern your own engineers can reuse for the next one without starting from nothing.

03 · Agriculture & food production

Grading from a photograph, on the line

The problem: Produce is graded by eye. Standards drift between shifts and between sites, disputes with buyers come down to one person's judgement against another's, and training a new grader takes weeks nobody has during a harvest.
What we build: A vision model trained on your own graded samples, running on a camera at the line: categorising, flagging defects and keeping an image for every decision. Anything it is not confident about goes to a person rather than being guessed, and the confidence threshold is yours to set and change.
What changes: Consistent grading across shifts and sites, an image record behind every batch when a buyer queries it, and new staff learning against a documented standard rather than against whoever happened to train them.

The technology

The tools behind it, named

Custom features mix bought intelligence with built intelligence. Most of the time an API is the right answer; sometimes your own data makes a small model you own both better and enormously cheaper, and part of our job is telling you which case you are actually in.

6 layers · 33 technologies

Bought intelligence

Frontier models through an API, the fastest route to a working feature, and frequently the right permanent answer for anything language-shaped.

Anthropic Claude
OpenAI
Google Gemini
Mistral
Replicate
Hugging Face

Built intelligence

Where your own labelled data is the advantage (image grading, classification, forecasting, ranking), a small model you own can be more accurate and orders of magnitude cheaper to run than any API.

PyTorch
scikit-learn
OpenCV
ONNX
pandas

Search & recommendations

The two features most often requested and most often built badly. Meaning-based retrieval combined with exact matching and your own behavioural data.

Qdrant
PostgreSQL + pgvector
Elasticsearch
Meilisearch
Algolia

Serving it inside your product

The feature has to live in your codebase, behind your authentication, inside your latency budget, not in a separate service your team cannot deploy.

FastAPI
Python
TypeScript
Next.js
React
Node.js

Where it runs

Close to your users for latency, in your own cloud where the data must stay, and able to absorb a launch without paying for that capacity permanently.

Cloudflare
Vercel
AWS
Google Cloud
Microsoft Azure
Docker

Keeping it honest in production

Evaluation sets, tracing on every request, cost and latency dashboards, and alerts when quality drifts, because a model's behaviour can change even when your code has not.

Langfuse
PostHog
Grafana
Sentry
Redis

Product names and logos are the property of their respective owners and are shown to describe the technologies we work with. Their use does not imply any partnership, sponsorship or endorsement.

How we deliver it

Live behind a human first

Around six weeks to a feature in front of a subset of your users. We would rather ship one narrow thing that works than four that demonstrate well and get switched off.

We pick the feature on evidence

Support tickets, session recordings, the things users ask for and the steps where they give up. The best candidate is usually something small and repetitive that customers already do by hand inside your product, rarely the ambitious item at the top of the roadmap.

We check the data honestly

How much do you have, how clean is it, is any of it labelled, and are you legally entitled to use it. This is the point where "we will train our own model" often becomes "we will call an API for now", and it is very much cheaper to learn that in week one.

We build the smallest version that could work

A rule before an API call, and an API call before a trained model. If the simple version is good enough it ships, and you have not paid for sophistication your users could never have detected.

We measure it against having no feature

An evaluation set with known good answers, plus a live comparison against your current behaviour. The question is never whether the model is impressive; it is whether users do something different because of it.

It ships behind a flag

Internal users, then a small percentage of accounts, then everyone, with cost, latency and quality watched at each step, and a switch that turns it off without a deployment if any of the three goes the wrong way.

Then it is maintained like a feature

Ongoing evaluation, cost tracking, and periodic re-testing against newer models. This layer moves quickly, and a feature built properly should get cheaper and better each year rather than slowly rotting in place.

Before you commit

The questions worth asking

Do we even have enough data for this?

Often less is needed than people assume, and occasionally there is genuinely not enough. Anything language-shaped usually needs no training data at all. A frontier model plus your content is sufficient. Training your own vision or scoring model realistically needs hundreds to thousands of labelled examples, and if you do not have them the honest answer is either "start collecting them now" or "use an API and revisit in a year". We tell you which in the first fortnight rather than after a project has been signed.

Won't the model providers just build this and make it worthless?

Some of it, yes. Anything that is a thin wrapper around a general capability gets commoditised, and faster than most people expect. What does not get commoditised is a feature resting on your data, your customers' behaviour and your domain's specific rules. We steer you towards the second kind, and we will say plainly when an idea is the first kind rather than build it and take the money.

How do we stop it embarrassing us in front of customers?

By assuming it will get things wrong and designing for that: suggestions a user confirms rather than actions taken silently, confidence thresholds that withhold a weak answer instead of displaying it, hard rules about what it may never output, and adversarial testing before release against the specific failure that would hurt you most. A wrong suggestion someone can ignore is survivable; a wrong action taken automatically on their behalf is not.

What will it cost to run at scale?

It is modelled before we build, using your real traffic rather than an average. The costs that hurt are always the unprojected ones, a feature on a free tier called on every page load, or an expensive model doing careful work for users who will never convert. We design the caching, the model tiering and the hard caps up front and report cost per request, so a growth spike becomes a capacity decision rather than a shock.

Can this run without sending data to a third party?

Yes, with trade-offs we will show you rather than gloss over. Open models running in your own infrastructure handle a great deal of what gets asked of them, and for vision and classification a model you own is frequently better than any general API. For the hardest language reasoning there is still a real capability gap between open and frontier models, and pretending otherwise would be dishonest.

Who owns what you build?

You do: the code, the prompts, the trained weights, the evaluation sets and the data. It runs in your infrastructure or in an account you control, and it is documented well enough that another team could pick it up. We are not interested in building you something you cannot leave.

What could your product do that it can't today?

Tell us the step your customers do by hand inside your product. We will tell you whether AI removes it, roughly what it would cost per user, and whether it is worth shipping.

Start the conversation →

Explore more

The rest of AI & Automation

Assistants & chatbots Document intelligence Knowledge search Workflow automation Team copilots ← All of AI