How to Choose a Company to Build Custom Machine Learning Models
Half of “we need a custom ML model” briefs are really LLM-plus-retrieval jobs that need no training. When you genuinely need bespoke machine learning, choose the partner on data honesty and evaluation, not its model zoo.
“We need a custom machine learning model” is, most of the time, the wrong sentence. Around half the requests for custom machine learning model development that reach us turn out to be retrieval problems an LLM solves with no training at all. The other half are real. The job before hiring anyone is telling which half you are in, because the two need different partners, different budgets, and different timelines.
Do you need a trained model, or an LLM with the right context?
In 2026, a lot of work that used to require a bespoke machine learning model no longer does. Classification, extraction, summarisation, question answering over your documents: a general LLM plus a retrieval layer handles these with zero training, in days, for a few thousand euros. If that is your problem, you do not want a machine learning development company. You want someone who wires up context well.
Real machine learning earns its keep in narrower places. Forecasting on your own time-series data. Classification on proprietary numbers where no public model has seen your distribution. Tight latency or cost at high volume, where a small trained model beats calling a large one a million times a day. Computer vision on images only your business owns. When the task is one of those, a trained model is the right tool, and the partner question becomes real.
A fast self-test: is the hard part understanding language, or finding a pattern in your own numbers and images? Language points to an LLM. Patterns in proprietary data point to custom machine learning model development.
What separates a real machine learning development company
Once you know you need a trained model, the selection criteria are not about how many architectures a firm can name. They are about discipline.
- They ask about your data first. Before talking models, a serious team asks how much data you have, whether it is labelled, how clean it is, and how fast it drifts. No data conversation in the first call is a red flag.
- They have an evaluation plan. A held-out validation set, a metric tied to your business outcome, and an honest baseline. “It looks good” is not evaluation. Ask what number they will report and how they will measure it before any training starts.
- They try the dumb thing first. A good team runs a simple baseline, a heuristic or a logistic regression, before reaching for anything heavier. If the baseline is close enough, they tell you. That honesty saves you a model you do not need.
- They plan for the second year. A model is not a deliverable, it is a thing that decays. Ask how retraining works, who monitors for drift, and what the pipeline costs to run. A team that only quotes the build has not thought about month 13.
- They will tell you not to train. The best machine learning development company will sometimes end the first meeting by saying you do not need them. That is the signal you found a good one.
The failure mode is almost always the data, not the model
When a custom model project stalls, the post-mortem rarely blames the architecture. It blames the data: there was not enough of it, it was not labelled, or it had never been logged in a usable form. A team that wants to train a custom ML model on three weeks of hastily exported spreadsheets will produce a confident model that fails the moment real inputs arrive.
This is the same root cause behind most stalled AI work generally, which we unpack in why most AI projects fail. The practical move is to treat data readiness as the first milestone, not an assumption. A vendor worth hiring will scope that honestly, and a paid audit is where it gets caught before the budget is committed. You can see the range of systems that come out of that approach across our case studies, and the model and tooling layer we actually build on in what we build.
When a bespoke machine learning model is the wrong call
- An LLM with retrieval already does it. If the task is about language or documents, train nothing. Wire up context instead.
- A hosted API covers it. Speech-to-text, common-object vision, translation: these are solved products. Calling one beats training your own unless your domain is genuinely unusual.
- You lack labelled data. No labels, no supervised model. Either label a meaningful sample first or pick a method that does not need them. A vendor who waves this away is selling you a problem.
- Half of custom ML requests are really LLM-plus-retrieval jobs that need no training. Decide which half you are in first.
- Real machine learning earns its place on proprietary numbers, time-series, high-volume latency, and your own images.
- Choose the company on data honesty, an evaluation plan, baseline discipline, and a retraining story, not its model list.
- The best partner will sometimes tell you not to train a model at all.
- Stalled model projects almost always trace to data, not architecture. Treat data readiness as milestone one.
Before you hire anyone to train a custom ML model, it is worth knowing whether you need one. gamgi’s two-week audit separates the genuine machine learning problems from the retrieval problems wearing an ML costume, and scopes the data work honestly before a line of training code is written. What would your model actually predict, and do you have the data to teach it?
Book your AI audit
