Model Training & Evaluation
Supervised and unsupervised models trained on your data and benchmarked against honest baselines and held-out sets before anyone calls them done.
AI Development · 01 Custom ML Solutions
Bespoke models trained on your data, taken from prototype to production-grade MLOps. We build the pipelines, train and tune the model, deploy it into your systems, and monitor it so it keeps earning its place long after launch.
You own the models, code and IP Weekly demos Reply within one business day
Forecast engine
Demand forecast - next 8 weeks
94.2%
Accuracy
+18%
Vs baseline
8w
Horizon
Retrained nightly on 14 months of order behaviour.
OlDevs builds custom machine learning models trained on a client's own data, then takes them from prototype to production with data pipelines, MLOps tooling, deployment, and ongoing tuning.The service is for corporations, associations, government bodies, franchises, and entrepreneurs who need a model fitted to a specific business problem rather than an off-the-shelf tool. Every engagement ends with a monitored, documented model that the client owns outright, delivered from OlDevs' studio in Vancouver, British Columbia.
Key facts
01 · Custom ML Solutions
What we deliver in Custom ML Solutions
Supervised and unsupervised models trained on your data and benchmarked against honest baselines and held-out sets before anyone calls them done.
Supervised learning · Unsupervised · Baselines · Cross-validation · Metrics
Reproducible pipelines that clean, join, validate, and version your data so features are identical between training and live inference.
ETL · Feature store · Data validation · Versioning · Schemas
Systematic search, ablation, and regularisation that trade model size against accuracy and latency in whichever direction your use case needs.
Bayesian search · Ablation · Regularisation · Quantisation · Latency
Containerised inference behind a versioned API, scheduled batch job, or edge runtime, with canary rollout and one-step rollback built in.
REST and gRPC APIs · Batch inference · Containers · Edge runtime · Canary rollout
Experiment tracking, a model registry, CI/CD for models, and reproducible training runs so any result can be traced, audited, and rebuilt.
MLflow · Model registry · CI/CD · Reproducibility · Lineage
Live monitoring of accuracy, input drift, and data quality, with alerting and retraining schedules that keep the model honest over time.
Drift detection · Alerting · Retraining · Dashboards · Data quality
Process
Scope
Define the prediction, the decision it informs, the success metric, and the baseline the model must beat.
Data
Audit, clean, and version your data, then build the pipeline and feature set the model will train on.
Train
Iterate on architectures and hyperparameters against held-out data until the model clears the agreed bar.
Deploy
Package the model, wire it into your systems, and release it behind a versioned endpoint with rollback.
Monitor
Track drift, latency, and accuracy in production, and retrain on a schedule or when a threshold is crossed.
How we work
We start every project with a simple heuristic or linear model so each gain is measured against something real, not against nothing.
Training, validation, and test sets are fixed and time-aware before modelling begins, so results are never flattered by leakage.
Each run is recorded with its code, data version, parameters, and metrics; nothing ships that cannot be reproduced on demand.
The same feature code runs in training and in production, which removes the most common source of silent accuracy loss.
Models are containerised and deployed behind versioned endpoints with canary releases, so a bad model can be reverted in minutes.
Post-launch monitoring tracks prediction and input drift, and the retraining plan is agreed before launch rather than after the first incident.
Who it's for
Whether the audience is a customer, a member, a citizen, or your own team, the work has to hold up under real use.
Enterprises with proprietary data and a use case no vendor model fits: demand forecasting, risk scoring, quality inspection, dynamic pricing. We build the model and the MLOps that keeps it governed.
Public bodies and member organisations that need explainable, auditable models on sensitive data, deployed within Canadian data-residency and privacy requirements.
Multi-location brands with data from dozens or hundreds of sites: one model trained across the network, serving location-level predictions from a single deployment.
Founders whose product depends on a model that does not exist yet. We take it from notebook to a production service that customers and investors can rely on.
12+
years building software in Vancouver, since 2014
3–6 wks
typical time to a working prototype on client data
99.9%
inference uptime across monitored deployments
Works well with
Chatbots, copilots, and RAG systems on leading language models, fine-tuned to your domain.
Explore03Classification, sentiment, entity extraction, semantic search, and translation.
Explore04Image & video recognition, object detection, OCR, and automated quality inspection.
ExploreSelected work
Client names are withheld; the problem and the outcome are the point.
“We stopped arguing about the weather on Monday morning, because the route plan is already on the screen when dispatch opens.”
Challenge
Delivery volume swung with the weather, but the weekly plan was a spreadsheet one person rebuilt every Monday from last year's numbers and a feel for how cold it was going to get. Trucks ran half empty in mild weeks and missed customers during cold snaps, and the emergency refills that followed consumed the margin on long rural routes. Nobody could say in advance which of the six depots was about to run short.
Solution
We built a demand model at the level of the individual customer tank, trained on three years of delivery history, tank telemetry and degree day records, using gradient boosted trees in Python. Forecasts run nightly and land in the dispatch board the planners already work from, each with a confidence band so they know when to hold capacity in reserve. Planner overrides are captured and fed back as a training signal rather than lost in a side file.
“Our client managers start the day with twenty names instead of a feeling about who has gone quiet.”
Challenge
Churn only became visible once a client stopped answering emails, which was usually a month after they had already decided to leave. Client managers had a shared spreadsheet of hunches and no way to rank 1,800 accounts by who needed a call this week. Two partners were effectively reviewing the book from memory.
Solution
We trained a churn model on billing history, support ticket patterns and client portal activity, with monthly features assembled in a small Postgres feature store and every client scored overnight. The score and the three factors driving it are written back into HubSpot as account properties, so a manager opening a record sees the risk band and the reason without leaving the CRM. A daily view surfaces the twenty accounts worth a call, and what happens on those calls is logged and used to retrain the model each quarter.
No stories match that filter yet.
FAQ
A working prototype on your data typically takes three to six weeks, depending on how ready the data is. Taking that prototype to a production deployment with pipelines, monitoring, and handover usually adds another six to twelve weeks. We agree milestones at the scoping stage and report progress against them every week.
Three things: a clear description of the decision the model should support, access to a representative sample of your historical data (even if it is messy), and one person on your side who can answer domain questions. You do not need a data science team or clean data; the pipeline and clean-up work is part of the engagement.
We work primarily in Python, using PyTorch, scikit-learn, XGBoost, and LightGBM for modelling, MLflow or Weights & Biases for experiment tracking, and Docker and Kubernetes for serving. We deploy to AWS, Google Cloud, Azure, or on-premises infrastructure, and we can build inside SageMaker, Vertex AI, or Azure ML if your organisation has standardised on one.
Before training starts we agree the metric that matters for your decision, such as precision at a threshold, mean absolute error, or ranking quality, along with a baseline it must beat. During the build you receive a weekly summary of experiments and results. After launch, a monitoring dashboard tracks live accuracy, data drift, latency, and error rates, and we send a monthly performance report with a recommendation on retraining.
You do. Every model weight, training script, pipeline, and piece of infrastructure code is delivered into repositories and cloud accounts you control, and your data never leaves environments you own. OlDevs retains no rights to reuse your data or your trained models, and nothing we build is locked to our continued involvement.
However suits you. Some clients hand us the problem and receive a running service; others embed our engineers alongside their data or IT team with shared repositories, stand-ups, and code review. Either way we document everything and run a handover so your team can operate, retrain, and extend the model without us.
It depends on the scope: the state of your data, the complexity of the model, and how much MLOps infrastructure you already have in place. Rather than quote a generic figure, we scope each project individually. Request a quote with a short description of your use case and we will reply within one business day with a proposed approach and pricing.
Let’s connect
Tell us what you’re building. We’ll reply within one business day with next steps and a tailored quote — no obligation.
Thanks — we’ll reply within one business day.