We build machine learning models that are trained reproducibly, evaluated against a clear baseline, and packaged so they can be deployed and maintained like any other piece of software.
What we build
A useful model is more than a trained file. It is a dataset definition, a training procedure, an evaluation, and a way to serve predictions. We build all four, for problems such as:
- Classification and regression on tabular data: risk and propensity scoring, pricing inputs, prioritization, anomaly flags.
- Time series and forecasting models for demand, load and usage, with backtesting that mimics how the model will actually be used.
- Ranking and recommendation for search results, catalogs and work queues.
- Anomaly and fraud detection where labels are scarce and the cost of false alarms matters.
- Deep learning in PyTorch where the data and the problem justify it, such as sequence, text or image inputs.
We lean toward the simplest model that meets the requirement. A well-tuned gradient boosted model with good features beats an unmaintainable network more often than people expect. Where text or images are the main input, see NLP and LLM applications and computer vision.
How an engagement runs
- Define the target and the metric. We agree what is being predicted, how a prediction will be used, which errors cost the most, and what number the model has to beat.
- Prepare data and splits. We build the training dataset, guard against leakage, and choose validation splits that reflect real use, for example splitting by time or by customer.
- Establish a baseline. A rules-based or linear baseline sets the bar, and we record it.
- Train and compare. Candidate models are trained with tracked experiments, so any result can be rerun from the commit and configuration that produced it.
- Evaluate beyond the headline number. We inspect errors by segment, calibration, stability across time, and behavior on edge cases, and we write up the limits.
- Package for deployment. The chosen model gets a versioned artifact, an inference interface, tests and a container image, ready to hand to your platform team or to our MLOps work.
Typical stack
- Python, scikit-learn, XGBoost or LightGBM for tabular models; PyTorch for neural networks.
- pandas or Polars for data preparation; Parquet files or SQL sources for training data.
- Experiment tracking such as MLflow or Weights & Biases, or plain structured logs if you prefer fewer tools.
- FastAPI for online inference; batch scoring jobs for scheduled predictions.
- Docker for packaging, and GitHub Actions or your CI for tests and builds.
Deliverables
- Training code, configuration and pinned dependencies in your repository.
- An evaluation report: baseline, final model, error analysis, and known limitations.
- A versioned model artifact and a documented inference interface.
- Unit tests for feature code and a smoke test for the serving path.
- A handover session and a short runbook covering retraining and rollback.
What we ask from you
Access to representative data, a person who can explain how the target is defined in the business, and a decision-maker who can say what a wrong prediction costs. Without those, no amount of modelling skill produces a useful system. If the data is personal, we also want to know what you may use it for; our guide to data mapping and discovery covers how teams find out what they hold.
Beyond the model
Most of the risk in a machine learning project is outside the algorithm: unclear targets, leaky features, unrepresentative data and a mismatch between how the model is tested and how it will be used. We spend time on those early and document the decisions, so a reviewer can follow why the model was built the way it was. We also keep a record of what was tried and rejected, because the failed experiments often explain more about the data than the successful one, and they save the next engineer from repeating them.
Frequently asked questions
Do you only work with deep learning?
No. Many problems are better served by classical methods. We pick the approach that meets the requirement with the least operational burden.
Can you take over a model someone else built?
Yes. We start by reproducing the existing results, adding tests and an evaluation, and then improving or deploying it.
How do we know the model is good enough?
We agree acceptance criteria in advance, tied to a baseline and to the cost of errors, and report against them. We do not promise a particular accuracy before seeing the data.
Who owns the model and the code?
You do. Everything is delivered into your repositories and accounts.
What happens after launch?
Models degrade as the world changes. We can set up monitoring and retraining, described under MLOps, or leave your team with a runbook.
Request a quote
Tell us what you want to predict, what data you have, and how the prediction will be used.
See all services, or read about data science if you are still shaping the question.