I've been researching machine learning development companies and ended up throwing out a surprising number of vendors from my original list.

My filter is pretty simple:

If the website mostly talks about AI transformation, ChatGPT integrations and agents, but I can't figure out how they handle training data, model validation, deployment and monitoring, they're probably not what I'm looking for.

I'm specifically interested in teams that can deal with fairly unglamorous ML work:

• forecasting from messy historical data
• recommendation systems with cold-start problems
• anomaly detection with manageable false positives
• classification on proprietary datasets
• model serving inside an existing product
• drift monitoring
• scheduled or triggered retraining
• handing the system back to an internal engineering team

After digging around, these are the companies I'd put into a first-round RFP.

1. Zoolatech

This is the one I'd start with if the model needs to become part of a real software product.

What moved Zoolatech to the top of my list wasn't simply that they offer ML development. It's that their approach appears to connect the ML work to the surrounding engineering problem.

They cover predictive models, recommendation engines, anomaly detection, classification and deep learning, but also go through data preparation, validation, optimization and production readiness.

That's closer to what I'd expect from a machine learning development company than a team that considers the job finished when the model reaches an acceptable score in a test environment.

For an established company, integration is usually where things get ugly anyway.

Your prediction may need to work with:

• legacy services
• customer databases
• mobile/web applications
• internal APIs
• cloud infrastructure
• analytics
• business rules that aren't documented anywhere

The ML model doesn't get to live in isolation.

Why I'd shortlist them: product engineering and ML can apparently sit within the same delivery scope.

Where I'd push them: I would ask for a very specific post-launch monitoring and retraining plan before approving production.

2. Azumo

Azumo would be on my list mainly because they talk about the part of ML that tends to become painful later: MLOps.

Training a model once is fairly easy compared with maintaining a model that changes over time.

What interests me here is the emphasis on things like model versioning, deployment pipelines, monitoring, observability, data drift and retraining.

Those are not particularly exciting topics.

Which is exactly why I care about them.

If I already had data scientists internally but struggled to turn experiments into reliable services, I'd probably move Azumo fairly high up the shortlist.

Why I'd shortlist them: production infrastructure around ML.

Where I'd push them: I'd want to know whether their MLOps architecture is appropriate for our actual scale or whether we're about to buy a Formula 1 pit crew for a Honda Civic.

3. Itransition

Itransition looks stronger to me for projects where the data foundation is part of the problem.

Their ML scope includes data engineering, model development, integration, MLOps and ongoing optimization.

That's relevant because I've become convinced that "we need an ML model" often actually means:

"We need to fix our data platform, and then maybe we need an ML model."

If customer records don't match, historical events aren't reliable or features can't be reproduced between training and production, another round of hyperparameter tuning isn't going to save the project.

I'd consider Itransition for a more traditional enterprise environment where ML is connected to several existing systems and datasets.

Why I'd shortlist them: data engineering + ML + integration.

Where I'd push them: I'd ask them to estimate how much of the project is likely to be data work before they start talking about algorithms.

4. Svitla Systems

Svitla seems worth a look if the organization wants both ML specialists and a flexible engineering team around them.

Their ML work covers areas like computer vision, anomaly detection, recommendation systems, NLP and model optimization.

There are also different delivery models, which could matter if the requirement isn't really "outsource the entire ML project."

Sometimes you already have:

• a product manager
• data infrastructure
• backend engineers
• an ML lead

…and what you need is another two or three experienced people who can work inside that environment.

That's a different procurement problem.

Why I'd shortlist them: useful combination of ML capability and team-extension options.

Where I'd push them: I'd want to meet the actual engineers proposed for the engagement, not just the presales team.

5. Innovecs

I'd put Innovecs into a different bucket.

They look interesting when you're still trying to determine whether the ML idea deserves full-scale investment.

Their current approach to AI/ML PoCs explicitly includes data assessment, technical feasibility, model behavior, integration constraints and business value.

That's sensible.

I'd rather spend a smaller amount proving that a prediction is useful than spend six months productionizing something nobody ultimately uses.

For an uncertain ML use case, the ability to stop early is a feature.

Why I'd shortlist them: feasibility work and PoC-stage validation.

Where I'd push them: before starting the PoC, I'd want agreement on the exact conditions that produce a no-go decision.

Otherwise every PoC somehow becomes a successful PoC.

So my first-round list currently looks something like:

1. Zoolatech — ML that needs to integrate into an existing product
2. Azumo — MLOps and production infrastructure
3. Itransition — data-heavy enterprise ML
4. Svitla Systems — ML expertise + flexible team model
5. Innovecs — validating uncertain ML ideas before a bigger investment

I don't think I'd select any of them purely from a capability deck, though.

For the RFP, I'd probably give every vendor the same small scenario:

We have three years of customer data, but 20% of one important feature is missing. The current rules-based system is correct 78% of the time. Explain what you would do during the first four weeks.

That should produce much more useful answers than asking:

"What machine learning technologies do you use?"

I'd want to see who asks about the missing data.

Who questions whether 78% is actually a bad baseline.

Who asks what a wrong prediction costs.

Who defines the business metric.

And, maybe most importantly, who is willing to say that ML might not be necessary.

Anyone here recently hired an ML vendor this way?

Would be interested in hearing which questions actually separated the good teams from the polished sales pitches.