Machine learning development
Machine Learning Development Company for Custom Business Solutions
Meronym builds forecasting, detection, vision and ranking systems, then measures each one against the method your team uses today. This page covers four things worth checking with any machine learning development company, including us: which approach fits, what data it needs, how it will be judged, and what the engagement costs.
| Run | Against today | Scored on | Verdict |
|---|---|---|---|
| Last year plus growth | the bar | held-out weeks | today's method |
| Seasonal naive | reference | held-out weeks | kept for context |
| Candidate model | beats it | held-out weeks | ships |
| Larger candidate | no gain | held-out weeks | not worth the cost |
Example log: every candidate is scored on the same held-out data as your current method, and ships only if it beats it.
The ML stack
Platforms these models run on
AWS SageMakerML platform
Vertex AIML platform
Azure MLML platform
PyTorchModelling
TensorFlowModelling
ONNX RuntimeModel serving- AWS SageMakerML platform
- Vertex AIML platform
- Azure MLML platform
- PyTorchModelling
- TensorFlowModelling
- ONNX RuntimeModel serving
The service
What a machine learning development company actually delivers
A machine learning development company builds a system that supports a decision: how many units to order, which claim needs faster review, which machine to service this week, or which part needs inspection. The model is one part of that system. The deliverable also includes the data pipeline, the path that brings the prediction into people's work, monitoring, and documentation that helps someone other than the original author understand and defend it.
Expect roughly a third of the effort on data and features, a third on modelling and validation, and a third on serving, monitoring and retraining. Teams that buy only the middle third get a notebook with a good number in it and no way to run it. That ratio is also why machine learning consulting and machine learning development are not separate purchases here: the advice that matters is about your data, and it arrives by working on it.
This page is written for people choosing a machine learning development company who need to understand fit, data readiness and cost before a call. Each section gives your technical and business teams something concrete to compare with their own situation. If the data needs work first, the data-floor section helps make that visible early.
- Baseline
- Measured first
- The current method is scored on the same held-out data as the candidate model.
- Release decision
- Evidence led
- A model moves forward only when the agreed metric and operational checks support it.
- Ownership
- Named before launch
- A data owner and a decision owner are part of the delivery team.
01 · Decide
Machine learning, a language model, rules, or something you can buy
Machine learning, language models, rules and established products suit different kinds of work. Choosing the simplest suitable approach helps your team control cost, explain the result and operate it with confidence. We settle that question before designing the rest of the project.
| Approach | When it is the right answer | What you need first | What it costs | Verdict |
|---|---|---|---|---|
| Classical machine learning | You are predicting a number or a category from history that your systems already record: demand, risk, failure, fraud, churn, price. | History at the grain you want to predict, with the target defined one way, and a record of when the process changed. | $20k–$94k for a production system. Tabular inference is usually inexpensive once the system is built. | The right answer when the question has a right answer you could look up later. |
| A language model | The signal lives in text, images or documents, or the output has to be written rather than scored. | The documents, and someone who can say whether an answer is right. Far less setup than a model, and you can try it this week. | No training cost, then a per-call bill that grows with every use and does not fall as you scale. | Faster to first result than anything else here. Wins on unstructured work and loses on arithmetic. |
| A rules engine | The policy is written down, has a named owner and must be auditable line by line. | The policy, and agreement on who changes it. | Cheapest to start. The cost is maintenance, and it arrives later than you expect. | Not a lesser option. If a rule can do it, a model is a liability with extra steps. |
| Something off the shelf | Your problem is the same shape as thousands of other companies' problems: spam, OCR, speech, common fraud patterns. | A shortlist and a procurement process. | A licence you can get quoted this week, against a build you cannot. | Check this first for solved problems. We will tell you when we think you are looking at one. |
02 · Sub-services
AI/ML development services we build
Seven applications, each with the data volume it realistically needs and the metric it is judged on. If your data does not clear the floor in the second column, that is worth knowing before a sales call with any machine learning development company, not after one.
- 01Fraud detection systemTransaction and claim scoring that routes cases to a review queue, with reason codes an investigator can act on rather than a score they have to trust.
- 02MLOps consultingFeature stores, training pipelines, registries, monitoring and the release gates that let a small team ship models without a senior engineer watching each one.
- 03AI personalizationRecommendation systems for ranking and next-best-action, measured on what the business actually got rather than on an offline score that improved.
- 04AI demand forecastingForecasts at the grain you plan on, holding up through promotions and seasonality, feeding the replenishment system rather than a planner's spreadsheet.
- 05Predictive maintenanceFailure prediction from sensor and maintenance history, tuned to the real asymmetry between a false alarm and an unplanned stop.
- 06Computer vision developmentDefect detection, counting, condition assessment and document imaging, trained on images from the cameras and lighting you actually have.
- 07Predictive analyticsChurn, propensity, credit and lifetime-value models, wired into the system where a named person or team reviews the score and acts on it.
03 · Approach picker
What shape is your problem?
Once you have settled that it is a model and not a language model or a rule, the shape of the question decides the approach, the data and how you will know it worked. Pick the closest match. Where a typical gain comes from one of our case studies it says so; the others are typical ranges, not a client's, and yours is measured against your own baseline in the feasibility sprint.
Sounds like
How many units of each product will we sell next month, in each location?
What we would try, in order
- 1stGradient-boosted trees on engineered calendar, price and promotion features
- 2ndHierarchical statistical forecasting where series are stable and low-volume
- 3rdDeep temporal models, only once the data volume justifies the operating cost
Where it goes wrong: a model fitted to history that had a pricing change halfway through it, so it forecasts a business you stopped running in March.
- Data you need
- Two years or more of history at the grain you want to forecast
- Metric
- WAPE or MASE against a seasonal naive baseline
- Baseline to beat
- Last year plus growth, which is harder to beat than it sounds
- Typical gain
- 10 to 25% lower forecast error than the baseline
- Time to first result
- 3–4 weeks
Sounds like
Which of these applications can be approved without a person reading them?
What we would try, in order
- 1stGradient-boosted trees on tabular features, with calibrated probabilities
- 2ndA text classifier on a pretrained language model, when the evidence is in notes rather than fields
- 3rdA rules layer above the model for constraints that are policy, not prediction
Where it goes wrong: training on labels produced by the process you are replacing, so the model learns the existing bias faithfully and reports it back as accuracy.
- Data you need
- 10,000 or more examples, with at least 500 of the rarer class
- Metric
- Precision at the threshold you will actually operate, plus calibration
- Baseline to beat
- Your existing approval rules, scored on the same held-out cases as the model
- Typical gain
- About 18 to 25% better detection accuracy, during the test, in our wildlife sound detection case study
- Time to first result
- 3–4 weeks
Sounds like
Which of last night's transactions should an analyst review this morning?
What we would try, in order
- 1stA supervised model wherever any labels exist, which beats unsupervised nearly always
- 2ndIsolation forests or autoencoder residuals for genuinely unlabelled data
- 3rdHand-written rules for the patterns you already know are bad, running next to the model
Where it goes wrong: an alert volume beyond the team's review capacity, which can lead people to mute the signal and lose confidence in the system.
- Data you need
- Ideally 1,000 confirmed anomalies, or failing that an honest review-capacity number
- Metric
- Precision at the review capacity you have, not the one you would like
- Baseline to beat
- The current thresholds, plus what your analysts catch unaided
- Typical gain
- 30 to 50% fewer false positives at the same catch rate
- Time to first result
- 3–4 weeks
Sounds like
Of the nine hundred leads that arrived this week, which twenty get called?
What we would try, in order
- 1stTwo-stage retrieval with a learned ranker on interaction data
- 2ndContent-based similarity for cold starts and sparse catalogues
- 3rdBandit exploration once traffic supports learning from it
Where it goes wrong: offline metrics improving while the business metric does not move, because the model optimised the thing that was easy to measure.
- Data you need
- 100,000 or more interaction events, ideally including what was not clicked
- Metric
- Online lift against a holdout group, never NDCG on its own
- Baseline to beat
- Ranking by popularity, which is stronger than almost anyone expects
- Typical gain
- A 5 to 15% lift on the primary metric against the holdout
- Time to first result
- 3–4 weeks, plus the agreed A/B window
Sounds like
Did this weld pass, and if it did not, whereabouts did it fail?
What we would try, in order
- 1stA fine-tuned vision backbone on your own labelled images
- 2ndSegmentation where the location and extent matter, not just presence
- 3rdSynthetic augmentation where defect examples are genuinely rare
Where it goes wrong: a model trained on clean sample photographs that collapses on the line, where lighting and angle change hour to hour.
- Data you need
- 1,000 or more images per class, captured on the hardware you will run on
- Metric
- Defect recall at a false-reject rate the line can absorb
- Baseline to beat
- Your inspectors' own pass and fail calls, measured on the same images as the model
- Typical gain
- 90 to 95% defect recall at the false-reject rate agreed with the line
- Time to first result
- 3–4 weeks after image capture and labelling
Sounds like
Forty thousand support comments arrived this quarter. What is in them, and what needs doing?
What we would try, in order
- 1stLanguage-model extraction into a fixed schema, then ordinary analysis on the structure
- 2ndA fine-tuned small classifier once volume makes the per-call cost matter
- 3rdTopic modelling, for work that is genuinely exploratory
Where it goes wrong: treating a language model's output as data without an agreed schema, leaving the team unable to compare this month with last month.
- Data you need
- The text, plus 200 to 500 examples a human has coded
- Metric
- Agreement with a human coder on a sample held back from training
- Baseline to beat
- Keyword tagging and a manual sample, which is what you do today
- Typical gain
- Every comment coded instead of a sample, at 85 to 90% agreement with a human coder
- Time to first result
- 3–4 weeks
04 · Data reality
Can your data support a machine learning model?
Many machine learning projects become difficult before modelling: the target is defined differently across systems, a process change in the historical data was not recorded, or a feature used for training is unavailable when a live prediction must be made.
A machine learning development company should check this in week one. We do, and if the honest answer is that you need a data engineering project before you need a model, we will say so and tell you what it would take. That is not a disclaimer. It means a feasibility sprint can end in a no, you keep the audit and the baseline, and neither of us spends four months finding out the expensive way.
See how we fix the data first| Check | Minimum | Comfortable |
|---|---|---|
| History length | 12 months | 24 to 36 months |
| Labelled examples | 1,000 | 10,000 or more |
| Share in the rarer class | 2% | 8% or more |
| Target definition | One agreed rule | Documented and versioned |
| Known process breaks | Flagged | Dated, and excluded from training |
| Features available at prediction time | Verified by hand | Served from a feature store |
| Person or team who will act on the score | Named | Their process is prepared to use it |
05 · Stack
The stack our machine learning development company builds on
Modelling
- XGBoost
- LightGBM
- scikit-learn
- PyTorch
- statsforecast
Gradient-boosted trees first for anything tabular, because they win on accuracy per hour of engineering and they are straightforward to explain to a risk function. Deep learning where the data is images, audio or sequence, and where the volume pays for the operating cost.
Data and features
- dbt
- Spark
- Airflow
- Dagster
- Feast
The feature definition has to be identical in training and in serving or the model will quietly score something different from what it learned. Roughly half the model bugs we are called in to fix live in this gap.
Training and tracking
- MLflow
- Weights & Biases
- Evidently
Every run records its data version, parameters and metrics, so a result can be defended months later by somebody who was not there. This is also what makes the experiment log publishable.
Serving and monitoring
- SageMaker
- Vertex AI
- Azure ML
- ONNX Runtime
- FastAPI
- Kubernetes
Your cloud account, your region, your network boundary. Batch scoring wherever the decision can wait, because real-time serving costs more to build and more to run, and a surprising share of predictions are consumed by a process that runs overnight.
06 · MLOps
After launch, the loop the model lives in
A model in production is a maintained asset, not a delivered artefact. This is the cycle a machine learning development company should build, and we either run it for you or hand it over with the tooling included.
- L1
Data and features
Pipelines, and one feature definition used by both training and serving. The failure here is silent: the model scores fine in testing and drifts the moment it meets live data.
dbt · Feast · Spark
- L2
Train and track
Reproducible runs with the data version, parameters and metrics recorded. Without that record, a promising result may be difficult for the team to reproduce later.
MLflow · Weights & Biases
- L3
Evaluate
Time-based splits, segment breakdowns and a fairness check wherever the decision affects a person. The failure here is an average that looks healthy while one segment is being quietly failed.
Evidently · custom suites
- L4
Deploy
Registry, staged rollout, shadow scoring against whatever runs today, and a rollback somebody has actually rehearsed. The failure here is a rollback path that exists only in the runbook.
SageMaker · KServe
- L5
Monitor
Input drift, prediction drift, latency, and the business metric. The failure here is alerting on the first three only, so the model degrades for a quarter while every technical dashboard stays green.
Grafana · Evidently
- L6
Retrain
Triggered by drift or by schedule, and gated by the same evaluation the first release had to pass. Nothing reaches production because a scheduled job succeeded.
Airflow · Dagster
07 · Deliverable
The model card you receive
Every model we ship comes with a one-page card: what it does, how well, on whom, and when to stop trusting it. Model risk functions at banks and insurers ask any machine learning development company for this; we write it either way, because it is also the document that lets your team keep the model after we leave. Below is what each section has to contain before we will sign one off.
- Purpose
- The decision the score feeds, named as a decision somebody makes.
- What the model is permitted to do on its own, and what it only recommends.
- Performance
- The metric at the threshold you will actually operate, not the best threshold.
- The incumbent's score on the same metric, the same data and the same window.
- Calibration, because a probability that is not calibrated is not a probability.
- Training data
- The window, the volume and the label count.
- Every known process break, dated, and whether it was excluded.
- What was deliberately left out, and why.
- Segment checks
- Performance broken down by the segments that matter commercially or legally.
- Any segment where the model is measurably weaker, stated as a number.
- How often the breakdown is rerun once the model is live.
- Known limits
- The populations and flows the model is not valid for.
- The conditions under which it degrades predictably.
- The uses it must not be put to, written plainly enough to survive a handover.
- Monitoring and retraining
- The drift threshold that raises an alert, and on which features.
- The retraining trigger and the evaluation gate it has to clear.
- The named owner on your side and ours.
08 · Cost
What hiring a machine learning development company costs
Feasibility sprint
$6k–$24kYour extract, a baseline, a first model and a straight answer on whether the accuracy you need is reachable. Credited against the build if you go ahead, and yours to keep if you do not.
3–4 weeks
One model to production
$20k–$94kData pipeline, model, serving path, monitoring, the model card and handover to whoever will own it.
10–16 weeks
Vision system
Quoted after image and hardware reviewPriced separately because it includes image capture on your hardware and a labelling programme, which are projects in their own right.
Set after capture and labelling review
MLOps platform
$12k–$59kFeature store, training pipelines, registry, monitoring and release gates, for a team that is shipping several models and cannot keep hand-building each one.
6–10 weeks
What moves the number
- Labels that do not exist yet. A labelling programme is its own project with its own timeline, and it is the single largest swing on this page.
- Features that exist in training but not at the moment of prediction. Common, and expensive in proportion to how late it is discovered.
- Model risk governance in a regulated setting: documentation, independent validation, sign-off cycles measured in weeks.
- Latency requirements that force real-time serving where batch scoring would have done.
- An existing warehouse with clean, dated history. Takes weeks off the front of the project.
- A named decision owner whose process will actually change when the score arrives. Cheaper to build for, and the strongest predictor we have of a model still running a year later.
Start with the feasibility sprint
As a machine learning development company we price engagements rather than hours, because an hourly rate tells you what a person costs and nothing about whether you will end up with a working model. The sprint is the smallest honest version of that: your data, a baseline, a first model, and an answer either way.
Book a feasibility sprint09 · Industries
Industries we build models for
- ManufacturingDefect detection on the line, and failure prediction on the assets that stop production when they go.
- Logistics and supply chainDemand and capacity forecasting at the grain planners actually order on, plus ETA prediction.
- Banking and financeScoring with reason codes and a model card, because the model risk function will ask for both.
- InsuranceClaims triage and fraud propensity, tuned to the cost of a wrong referral rather than to accuracy.
- Retail and e-commerceReplenishment forecasting and ranking, measured on margin and availability rather than on click-through.
- HealthcareOperational prediction: demand, no-shows, capacity and coding, kept well clear of clinical decisions.
Team
Who works on a machine learning engagement
Four roles from Meronym work alongside two roles from your team. The data owner and decision owner are essential: they connect the model to the people, definitions and operating changes that make its predictions useful.
| Role | What they own | Allocation |
|---|---|---|
| ML engineer | Features, modelling, validation, explainability, the model card | Set in scope |
| Data engineer | Pipelines, the training table, data contracts, the feature definition | Set in scope |
| MLOps engineer | Serving, monitoring, retraining, the rollback path and the running cost | Set in scope |
| Delivery lead | Scope, the weekly demo, and sharing early evidence when a build may not be justified | Set in scope |
| Data owner, yours | Access, the target definition, and confirming when the process changed | Set in scope |
| Decision owner, yours | The process the score feeds, and the authority to change it | Set in scope |
10 · Selected work
Models in production, and an example project
- Wildlife monitoring · Bird species by soundAbout 18 to 25% better detection accuracy, during the testBirdNET models adapted, with audio filtering, to name the birds in noisy field audio on listening stations, feeding the detections and live map people explore in the app.measured against: detection before the adapted models and the noise reduction, in the same testRead the case study
- Optician training · Consultation stages labelled liveAverage role-play session: about 25 minutes down to under 15The model reads each role-play as it happens and labels the consultation stage the learner has reached, correctly for 85 to 92% of stages in common scenarios, so feedback is scored against the right part of the guide.measured against: sessions before launch, at about 25 minutesRead the case study
- Example project · Retail lapse scoresLapse scores and value bands, with explanations, in the campaign toolAn example of the build this page describes: member-level lapse risk and value bands delivered to the campaign tool, with offers and budgets left to the CRM team.Read the case study
Read before you hire a machine learning development company
All guidesFAQs
Machine learning development company questions, answered
What does a machine learning development company do?
A machine learning development company builds the system around a prediction, not just the model: the pipeline that produces the features, the model itself, the serving path that carries the score into the system where a decision gets made, the monitoring that catches it degrading, and the documentation that lets somebody else own it. A model on its own is a notebook. The rest is what makes it a thing your business runs on.
How much does a machine learning development company charge?
A feasibility sprint is typically $6k–$24k, credited against the build if you go ahead. One production model is typically $20k–$94k, and an MLOps platform $12k–$59k. Vision work is quoted after reviewing the images, capture hardware and labelling needs. We price the engagement rather than the hour, and show labelling as a separate workstream when it is needed.
Do we need machine learning or an LLM?
If you are predicting a number or a category from history your systems already record, classical machine learning is cheaper to run, easier to explain and more accurate at that job. If the signal lives in text, documents or images, or the output has to be written rather than scored, a language model is the right tool and will get you there faster. Plenty of systems use both: a language model to turn documents into structured fields, then a model to predict from them. The table near the top of this page sets out all four options, including the two that are not AI at all.
How much data do we need to train a model?
It depends on the problem shape, which is why this page publishes a floor per application and a checklist you can run against your own extract. As rough orientation: around 10,000 labelled examples for a classifier, two years of history for a forecast, 1,000 images per class for vision. The volume is rarely the binding constraint, though. More projects are blocked by a target variable defined two different ways across two systems than by not having enough rows.
How long does a machine learning development services engagement take?
A feasibility sprint usually takes three to four weeks, a production model ten to sixteen weeks, and an MLOps platform six to ten weeks. Vision schedules are set after image capture and labelling are reviewed. Weekly demos let your team follow the evidence and accuracy trend throughout.
How do you keep models accurate after launch?
Drift monitoring on both the inputs and the predictions, performance tracking against ground truth as it arrives, retraining triggered by drift or by schedule, and an evaluation gate every retrained model has to clear before it replaces the live one. The point of the gate is that nothing reaches production because a scheduled job completed successfully. You also get the runbook, so your team can do all of this without us.
What is the difference between machine learning consulting and machine learning development?
Our feasibility sprint combines technical advice with hands-on work using your data. Over three to four weeks, it produces a documented baseline, a first model and a recommendation your team can act on, including a recommendation not to proceed when the evidence does not support a build.
How do you choose the best machine learning development company?
Four questions help compare providers. Ask what the model will be measured against, what data the problem needs, what documentation your team receives, and what happens if the candidate model does not improve on the baseline. A company that answers those questions with specific, reviewable evidence is worth considering, whether or not it appears on this page.
Who owns the model when a machine learning development company builds it?
You do: the model weights, the feature pipeline, the training set and the retraining code, all kept in your own repositories and cloud account. Ask the same of any machine learning development company you shortlist, and get the answer in writing, because those are four separate things and some suppliers keep more of them than you would assume.
What happens if the model does not beat the baseline?
The feasibility sprint exists so that you find this out in weeks rather than quarters, and it is a legitimate result rather than a failure. You keep the data audit, the documented baseline, the first model and a written account of what the ceiling looked like and why. In most cases we can also say what would change the answer, which is usually more labels, a cleaner target definition or a process break excluded from the history. That second project is sometimes worth more than the model would have been.
Start with the feasibility sprint
Send us the problem and a description of the data you hold. If it looks like a machine learning problem we will say so and scope the sprint. If it looks like a rules problem, a language-model problem or a data engineering problem, we will say that instead, and tell you what we would do about it.
You will get a reply from the engineer who would run the sprint, not a scheduling link.