A model that scores well on a sample is a nice thing to have. It is also the point where a lot of teams stall, because the next decision is not technical. It is about who carries the work from a promising experiment to a system that runs every day and keeps working when the world shifts underneath it.
There are roughly three routes. They are not equal, and none of them is wrong in every situation.
Staying in the notebook, and pretending that is the plan
This is the default, usually by accident. A data scientist builds something convincing, it gets shown around, and then it sits in a repository while everyone assumes someone else will productionise it.
It suits teams that genuinely only need a feasibility answer: can this data support the decision at all? That is a real and useful question, and answering it early is cheap. What it does not suit is anyone who needs the prediction inside a live product. The gap between a clean sample and real inference is where the pipeline, the serving layer, the versioning and the ownership all live, and none of that appears in a notebook. The common failure is a project that looks finished and changes nothing about the business.
The vendor build
Here the work is scoped as a delivery: data pipeline, a trained and evaluated model, deployment, monitoring, documentation, handover. The appeal is that the unglamorous parts are on the table from day one rather than discovered in month three.
It suits organisations with historical data and a repeated decision currently made by rules or instinct — recommendations, predictions, classification, anomaly detection. It also suits teams that already have a model limping along and need it turned into a system, or that want the training data to stay in-region and the documentation to survive an audit.
It does not suit everyone. If there is no historical data and no realistic way to collect any, no vendor can conjure a model from nothing. Nor is it the right call for original research or a novel architecture nobody has built before. A good partner will say so on the first call rather than take the budget. The thing to watch for is a build that stops at the model and quietly leaves the monitoring and handover out of scope — that is the same notebook problem wearing a contract.
Building it in-house
Doing it yourself makes sense when the model is close to the core of the product, when the team will keep iterating on it for years, and when the institutional knowledge is worth more than the speed. The cost is that you are hiring for data engineering, ML engineering and monitoring at the same time, and the drift problem arrives whether or not anyone owns it yet.
A model deployed without drift detection decays as fraud patterns, users and catalogues move away from its training data. The first person to notice is usually a customer. Whoever builds the system needs to treat that as part of the job, not an afterthought.
What a good result looks like
Whichever route you pick, the shape is the same. A feasibility answer in week one, before the budget is committed. A benchmark anyone in the business can understand. Monitoring that alerts when the model degrades. Documentation your own team can act on. If a route cannot give you those, it is not really a route to production.
The full guide to machine learning development in London covers the specific build stages, what each one contains and the signs that a project is drifting back toward the notebook — worth reading before you choose.
Top comments (0)