Machine Learning Services | ML Development & Deployment | Nordbeam

Here's a contrarian take: most companies don't need custom machine learning.

For prediction, classification, and recommendations, you can often get 80% of the value from well-configured off-the-shelf solutions or surprisingly simple heuristics. We've talked clients out of ML projects when simpler approaches would work—because the complexity of custom ML only makes sense when the payoff justifies it.

But when custom ML does make sense—when you have unique data, specialized requirements, or scale that justifies the investment—we build production-ready systems that actually work. Not impressive notebooks. Not conference-worthy prototypes. Working software that runs 24/7, handles edge cases, and improves over time.

The Notebook-to-Production Gap

Every data science team has notebooks full of promising models. Most never make it to production.

The notebook shows impressive accuracy on hold-out data. But deploying that model means building serving infrastructure, handling edge cases, monitoring for drift, setting up retraining pipelines, and integrating with systems that weren't designed for ML. The 2-week model development becomes a 6-month engineering project.

We've inherited plenty of these stalled projects. A 95% accurate model that fails silently on 5% of production inputs. A recommendation system that worked great in testing but adds 3 seconds of latency to every page load. A churn prediction model that was never retrained and now performs worse than random guessing.

Our approach starts with production in mind. We care as much about serving infrastructure, monitoring, and retraining as we do about the model itself—because without those, you don't have a working system. You have a demo.

What We've Built

Computer Vision at Volvo

For Volvo's vehicle software division, we built computer vision systems for safety applications. This wasn't typical ML work—it was automotive-grade reliability, real-time processing constraints, and integration with safety-critical systems.

The models needed to work in conditions that don't appear in standard benchmarks: low light, motion blur, weather effects, sensor degradation. We developed custom data augmentation pipelines to simulate these conditions, tested extensively on edge cases, and built monitoring that catches model drift before it affects performance.

The result: 40% improvement in processing efficiency, models running in production vehicles, and systems that have maintained their accuracy through multiple software updates.

Recommendation Systems at HSE24

Germany's largest home shopping network needed personalization that worked at scale without killing page performance. The challenge wasn't building a recommendation model—it was building one that returned results in under 100ms while handling their full product catalog.

We designed a two-stage architecture: a fast candidate generation layer that runs on every request, and a more sophisticated ranking layer that runs asynchronously. The system improved conversion rates by 35% while adding less than 50ms to page load times.

Predictive Maintenance for Manufacturing

For an industrial client, we built models that predict equipment failures before they happen. The payoff is significant—unplanned downtime costs more than scheduled maintenance, and knowing which machines need attention reduces unnecessary maintenance on healthy equipment.

The challenge was data quality. Sensor data was inconsistent, failure events were rare (which is good for operations, bad for training), and the cost of false positives and false negatives was asymmetric. We spent more time on feature engineering and data preprocessing than on model development—which is usually the right allocation.

When ML Makes Sense

Custom ML is worth the investment when:

You have unique data. If your competitive advantage comes from data that competitors don't have—proprietary sensor data, years of customer behavior, domain-specific labeled examples—custom ML can extract value that generic solutions can't.

Scale justifies complexity. A simple heuristic that works 80% of the time might be good enough for 1,000 decisions a month. For 1,000,000 decisions, the 20% error rate becomes expensive, and the investment in ML pays off.

The problem genuinely requires learning. Some problems look like ML problems but aren't. If you can write down rules that work, rules are more reliable. ML is for patterns that exist in data but are hard to articulate explicitly.

You're willing to maintain it. ML systems need ongoing attention—monitoring, retraining, debugging. If you can't commit to maintenance, the model will degrade. Sometimes starting with simpler solutions and adding ML later is the right path.

The Technology Stack

We're a PyTorch shop for custom model development. It's more flexible than TensorFlow for research and experimentation, and the gap in production tooling has closed. For classical ML, scikit-learn remains excellent—and often, classical ML is all you need.

PyTorch for deep learning because the ecosystem is strong, debugging is straightforward, and production deployment has improved dramatically with TorchServe and ONNX export.

Classical ML shouldn't be overlooked. Gradient boosting (XGBoost, LightGBM) often outperforms deep learning on tabular data, trains faster, and is easier to explain. We use deep learning when it's genuinely better, not because it's more impressive.

MLflow for experiment tracking because reproducibility matters. Every model we train has tracked hyperparameters, metrics, and artifacts. When something works, we can reproduce it. When something breaks, we can debug it.

AWS SageMaker for MLOps when clients are on AWS. It handles the infrastructure complexity reasonably well. For simpler deployments or non-AWS environments, we often use custom infrastructure with FastAPI and Docker.

MLOps: Why Models Fail in Production

The model that works perfectly in your notebook will fail in production for reasons that have nothing to do with the model itself.

Data drift. The world changes, and your training data becomes stale. Customer behavior shifts, product catalogs update, market conditions evolve. A model trained on 2023 data might perform poorly on 2025 inputs.

Infrastructure issues. The model that takes 100ms in a Jupyter notebook might take 2 seconds when it's competing for resources in production. Memory leaks in preprocessing code accumulate. Scaling issues emerge under load.

Silent failures. Unlike traditional software, ML systems can fail without throwing errors. The model returns predictions—they're just wrong. Without monitoring, you won't know until the business impact becomes visible.

We build all of this into our ML systems: monitoring that tracks prediction distributions and flags anomalies, retraining pipelines that update models on new data, infrastructure that handles scale reliably, and alerting that catches problems before users do.

Our Approach to ML Projects

Validate Before You Build

Every ML project starts with validation. We assess your data, define success metrics, and build a quick proof of concept. The goal is to know whether ML can solve your problem before you commit to a full build—not after you've spent six months trying.

A typical validation phase takes 4-6 weeks and answers: Does the data support the prediction we want to make? What accuracy is achievable? What will it take to get this into production?

Build for Production from Day One

We don't build notebook prototypes and then figure out deployment. We design the production architecture first, then develop the model within those constraints. This means thinking about latency requirements, scaling needs, and monitoring from the start—not as afterthoughts.

Maintain What We Build

ML systems need ongoing attention. Models drift. Data changes. New edge cases emerge. We provide ongoing support that includes model monitoring, periodic retraining, and continuous improvement based on production performance.

Specific ML Domains

Predictive Analytics

Forecasting future outcomes from historical data—the most common ML application. Sales forecasting, demand prediction, churn prediction, lead scoring. The patterns are well-established; the value is in execution.

Predictive models need baselines. Before deploying ML, we measure what simple approaches achieve. Often a well-tuned linear model beats a complex neural network on tabular data. ML should demonstrably outperform alternatives, not just theoretically.

Feature engineering is usually more important than model selection. Domain knowledge—understanding what drives the outcome you're predicting—translates into features that help the model learn. The best predictive systems are built by people who understand both ML and the business domain.

Predictions are only useful if they drive action. We design predictive systems with the decision they inform in mind. A churn prediction that's 90% accurate is less valuable than one that identifies interventions that actually reduce churn. The model is one component; the business process around it matters as much.

Natural Language Processing

Beyond LLMs, traditional NLP techniques remain valuable for many applications. Classification, entity extraction, sentiment analysis, topic modeling—these tasks don't always need the largest language models.

For high-volume, low-latency applications, smaller specialized models often outperform LLMs. A classifier trained on your specific domain runs faster and cheaper than sending every text to GPT-4 for classification.

We choose the right tool for the task. Simple keyword matching for straightforward routing. Rule-based extraction when patterns are clear. Statistical NLP when you have labeled data. LLMs when you need reasoning or generation. Most production NLP systems combine approaches.

Time Series Analysis

Sales patterns, sensor readings, user behavior over time—data with temporal structure requires specific techniques.

Standard ML often fails on time series. The correlation between yesterday and today matters; treating each observation independently loses information. We use models designed for sequences: ARIMA family for traditional forecasting, LSTMs and Transformers for complex patterns.

Anomaly detection in time series is particularly valuable. Detecting when metrics deviate from expected patterns—before problems become visible—enables proactive response. We've built monitoring systems that catch issues hours before they'd otherwise be noticed.

Forecasting uncertainty is as important as point predictions. A forecast of 1,000 units means different things with ±50 uncertainty versus ±500 uncertainty. We provide prediction intervals, not just point estimates, so decisions account for confidence.

Recommendation Systems

Beyond simple collaborative filtering, production recommendation systems address complex requirements.

Cold start—new users and new items—needs explicit handling. Content-based recommendations when behavioral data is sparse. Popularity fallbacks when nothing else is available. Exploration to gather data for personalization.

Business rules need integration. You might have inventory to move, margins to optimize, or content to promote. The recommendation algorithm optimizes for relevance; business logic adjusts for commercial objectives. The architecture needs to support both.

Diversity and serendipity matter for user experience. Recommendations that are all too similar become boring. We build systems that balance relevance with variety, personalizing while still surprising.

Classification Systems

Deciding which category something belongs to—documents, images, transactions, customers. Classification underlies countless applications.

Class imbalance is the most common challenge. When 99% of transactions are legitimate, a model that always predicts "legitimate" gets 99% accuracy but catches no fraud. We use sampling techniques, class weights, and appropriate metrics to build classifiers that work on imbalanced data.

Multi-class and multi-label classification require different approaches. A document that belongs to one category is different from a document that might belong to several. We design classification systems that match the actual structure of your problem.

Confidence thresholds turn classifiers into actionable systems. Rather than accepting all predictions, we route low-confidence predictions to human review. The threshold depends on the cost of errors—a 95% confidence threshold might be right for low-stakes decisions, 99.9% for high-stakes ones.

Model Deployment Patterns

Real-Time Inference

For interactive applications, the model must respond in milliseconds. This requires:

• Optimized model architectures—smaller models or distilled versions when latency matters
• Efficient serving infrastructure—GPU acceleration when beneficial, batching when possible
• Caching for repeated predictions on the same inputs
• Geographic distribution when users are global

We benchmark latency under realistic conditions—load, concurrent requests, production hardware—not just single-request tests on development machines.

Batch Inference

Many ML applications don't need real-time responses. Overnight scoring of customer segments. Daily forecasts. Weekly risk assessments. Batch processing is simpler, cheaper, and more efficient for appropriate use cases.

Batch systems need different design. Parallelization across large datasets. Checkpoint and recovery for long-running jobs. Output validation before downstream consumption. We design batch pipelines that run reliably, finish on schedule, and produce correct outputs.

Edge Deployment

Some applications need models running locally—mobile devices, IoT sensors, embedded systems. Edge deployment introduces constraints.

Model size must fit the device. Inference must run without network connectivity. Power consumption matters for battery-powered devices. We optimize models for edge deployment—quantization, pruning, architecture search—while maintaining acceptable accuracy.

The edge and cloud often work together. Edge models handle immediate decisions; cloud models handle complex cases or retraining. We design hybrid architectures that get the best of both.

Model Lifecycle Management

ML systems aren't static. They degrade, the world changes, and models need updates. Managing the full lifecycle—not just initial deployment—determines long-term success.

Retraining Strategies

Models drift because the world drifts. Customer behavior changes. Products evolve. Competitors shift the landscape. Models trained on historical data become increasingly misaligned with current reality.

Scheduled retraining on a regular cadence—weekly, monthly, quarterly depending on drift rate. Simple to implement, but risks retraining when unnecessary and missing drift between cycles.

Triggered retraining based on performance monitoring. When accuracy drops below threshold or drift metrics exceed bounds, retraining kicks off automatically. More efficient but requires robust monitoring.

Continuous training that updates models incrementally as new data arrives. The model is always learning. Complex to implement correctly—online learning has its own failure modes—but appropriate for rapidly changing domains.

A/B Testing Models

New models need validation beyond offline metrics. A/B testing in production reveals how models perform on real users with real consequences.

Shadow deployment runs new models alongside production without serving results to users. Compare outputs to detect regressions before exposure.

Gradual rollout exposes small percentages of traffic to new models. Monitor closely for problems. Increase exposure as confidence grows.

Automatic rollback when metrics degrade. The system should detect problems and revert without human intervention. Speed matters—problems compound the longer bad models serve traffic.

Model Versioning and Governance

Regulated industries require knowing what model made what decision when. Even without regulation, debugging production issues requires historical context.

Model registry tracks every trained model, its training data, hyperparameters, and performance metrics. You can answer "what model was live on March 15?" precisely.

Prediction logging stores inputs and outputs for critical decisions. Enables post-hoc analysis, debugging, and compliance reporting. Storage costs can be substantial for high-volume systems; sampling strategies help.

Audit trails for model changes. Who approved the new model? What testing was done? What's the rollback plan? Governance that would be overkill for experiments is essential for production systems.

Common ML Pitfalls

We've seen projects fail in predictable ways. Avoiding these pitfalls is as important as getting the technology right.

Overcomplicating Early

Teams jump to deep learning when gradient boosting would suffice. They build elaborate feature engineering pipelines before validating the base case. They optimize for scenarios that may never matter.

Start simple. Establish baselines with straightforward approaches. Add complexity only when simpler methods demonstrably fail. You can always make things more sophisticated; simplifying a complex system is much harder.

Ignoring Data Quality

"Garbage in, garbage out" applies with vengeance to ML. Models learn patterns in data—including patterns you don't want. Mislabeled training examples, biased samples, data entry errors, stale records—the model learns all of it.

Invest in data quality before model development. The time spent cleaning data and validating labels pays off in model performance. No amount of architectural sophistication compensates for bad data.

Optimizing the Wrong Metric

The metric you optimize isn't always the metric that matters. A model that maximizes accuracy might fail on the rare cases that cost the most. A recommender that optimizes click-through might decrease purchases. The loss function shapes behavior; choose it carefully.

Business metrics—revenue, conversion, efficiency—matter more than model metrics. We design evaluation frameworks that connect model performance to business outcomes, and optimize for what you actually care about.

Underinvesting in Monitoring

The excitement is building the model. The boring part is watching it run. Teams skip monitoring, then discover six months later that their model has been degrading since month two.

Monitoring isn't optional. It's as important as the model itself. A model without monitoring is a liability—you don't know if it's helping or hurting. We build monitoring into every deployment from day one.

Frequently Asked Questions

Related Services