Training a model is the easy part. The hard part is month 18, when the data has drifted, the integration broke, and the original team has moved on. We build for that month. Predictive models, NLP, forecasting, computer vision, and agentic LLM apps — with monitoring and retraining wired in from day one.
The notebook works on the data scientist's laptop. The slides land well. Then the model has to deal with real traffic, real schema changes, and a retraining cadence nobody owns — and the project quietly shuts down. This is the gap our engagements are built around.
The most-cited Gartner number, repeated by VentureBeat, Forrester, and a dozen others. The reasons rarely have to do with model quality. They have to do with data plumbing, ownership, and the absence of a retraining plan that survives a re-org.
Production data shifts. New customer segments appear. A pricing change moves the input distribution two standard deviations to the right. If the team only checks AUC at quarterly review, the model has already been wrong for a quarter.
Vendor invoices, internal headcount, cloud bills, and the harder-to-measure cost of decisions you postponed waiting for a model that never came. Most of that spend goes on the wrong things in the first six weeks — work a real discovery phase would have killed.
We don't take on a model class we haven't shipped before. The list below is what we'll quote on without hedging. If your problem doesn't fit, we'll tell you in the first call — and sometimes point you at someone better placed to help.
Churn, default risk, fraud, conversion, demand. The bread-and-butter classifiers and regressors that pay back inside a quarter when they're built well. Gradient-boosted trees by default. Deep learning only when there's a measurable reason to reach for it.
Classification, extraction, search, summarisation, sentiment. Built on transformer models — fine-tuned when the use case justifies it, prompted when it doesn't. Includes RAG systems where the model has to ground itself in your documents, not its training data.
Demand, capacity, financial planning, energy load. Where Prophet or ARIMA is the right answer, we'll use it. Where temporal models or hierarchical reconciliation are needed, we'll use those. The deliverable is always a forecast plus a calibrated uncertainty band, not a single point estimate.
Document classification, defect detection, quality inspection, OCR-adjacent extraction, and the long tail of "is this image what I think it is" problems. Often pairs with our DocPro engine when paperwork is involved. Edge deployment supported where the camera can't talk to the cloud.
Product recommendations, content ranking, lead prioritisation, vendor routing. Two-tower retrieval plus a re-ranker is the modern starting point. We're sceptical of recommenders without a clear offline metric and an even clearer online A/B plan — we'll insist on both before shipping.
Agents that read your documents, call your APIs, and route work to humans when they should. Tool-use, structured outputs, retries, evaluation harnesses, audit trails. Treated as production software, not a chatbot demo. The same SLA as the classifier next to it.
Most ML failures trace back to skipping discovery or skipping baselines. We do both, on purpose, and we'll walk away from a brief that doesn't survive them. It's cheaper for everyone.
Profile your data honestly. Write down the question worth answering. Define success in business metrics, not just F1. If the answer is "you don't need ML", you get that answer in week three, with the workings — and you stop.
Train something almost embarrassingly simple. Logistic regression. Gradient-boosted trees. A heuristic a domain expert wrote on a whiteboard. If the baseline solves it, we ship the baseline. If it doesn't, we now know what a real model has to beat.
Training pipeline, feature store where it earns its keep, evaluation harness, inference service with an SLA, integration into the system that consumes the prediction. Weekly releases in your environment. No big-bang launches.
Drift monitoring, scheduled retraining, on-call rotation, rollback path, model registry. The team that trained the model is the team paged when its inputs change shape at 3am. Not a separate ops desk reading a runbook for the first time.
We pick tools that the team inheriting the project can keep running. Open-source where it earns its place. Commercial APIs where they save you six months. Nothing here is a religion — if you already run a particular stack, we run it too.
More often than vendors will tell you. If a SQL query, a set of business rules, or a forecast a human writes once a quarter solves the problem, you don't need ML — you need a dashboard. We've walked away from briefs where the honest answer was "use a CASE statement". Pay for that conversation up front in discovery; it's cheaper than paying for it after six months of model development.
Three weeks for a baseline you can evaluate. The baseline is deliberately simple — logistic regression, gradient-boosted trees, a sensible heuristic — and it sets the floor. A real production model with monitoring, retraining, and integration usually goes live between week 10 and week 16, depending on data quality and how many systems it has to plug into.
Both, picked per problem. Classical ML problems usually stay on PyTorch, scikit-learn, or XGBoost — open-source, your hardware, predictable cost. LLM problems we'll often start with Claude or GPT to get to a working system fast, then evaluate whether an open-weights model like Llama or Mistral makes sense for cost, latency, or data-residency reasons. The architecture lets you swap providers without rewriting the application.
Monitoring is part of the build, not a Phase 2 conversation. Every production model ships with input-distribution checks, prediction-distribution checks, and performance tracking against ground truth when it becomes available. Retraining runs on a schedule and on a trigger — whichever fires first. If a model degrades faster than expected, the alert goes to the on-call engineer, not a quarterly review meeting.
We deploy where your data has to live. Most engagements run inside your AWS, Azure, or GCP tenancy. For regulated workloads we've delivered fully on-premise stacks running quantised open-weights models on a single GPU server, with no inference data leaving your network. We sign DPAs, support PII redaction at the ingestion layer, and have ISO 27001-aligned controls on our delivery process.
We start with whatever you have. Real production data is always messier than the brief suggests — missing labels, inconsistent schemas, fields that mean different things in different years. The discovery phase profiles all of that honestly. Sometimes the answer is "fix the upstream system first"; sometimes it's "model it the way it is, and document the assumptions". We'll tell you which.
You do, from day one. Code lives in your repo. Model weights live in your registry. Training data stays in your warehouse. There is no proprietary framework you get locked into. If you want to bring the work in-house in month 12, that's a successful outcome — we run a structured handover and stay on retainer for two months while your team takes over.
Both, and they're often the same engagement. A churn model that emails a retention agent is an LLM problem stitched to a classical ML problem. We treat agents as another kind of production system — tool schemas, retries, audit trails, evaluation harnesses, and a clear answer to "what happens when the model is wrong". The agent is held to the same SLA as the classifier.
Our engineering rate is the same whether we use Claude, GPT, an open-weights model, or no model at all. Inference cost is passed through at provider rates with no markup. The architecture is built so swapping models takes hours, not a re-platforming. That's what protects you from the next price cut or capability jump — a switch you make in a config file, not a contract.
Yes. We work inside whatever you already run — Snowflake, BigQuery, Databricks, Redshift, dbt, Airflow, Fabric. We don't ask you to migrate the warehouse to ship a model. If your data sits in SAP, Oracle, NetSuite, Dynamics, or Salesforce, we've built feature pipelines off all of them. Integration time is sized into the proposal, not discovered in week ten.
The one your internal team has been circling for two quarters. The one the previous vendor handed back as a notebook. We'll come back inside a week with an honest read on whether ML is the right answer — and if it is, a working path to month 18.
