From Model to Product

The churn model wins its tournament, clears the sealed final exam, and… nothing happens. Not one customer notices. Not one win-back email goes out. The winner is — remember Topic 04 — a file: learned numbers plus a recipe, sitting on a data scientist's laptop, changing exactly nothing about the world.

For customers to feel it, the model must become something the product can actually ask — a program that is always on, always reachable, always answering. Crossing that gap has a name: deployment. It is where the data team's work meets ordinary software engineering, and it is the half of every ML project that beginners never hear about.

Plateful production

Model servicethe model fileanswering wrapper

Real time — ask now"customer 4711?""churn risk 0.71"

Batch — nightly at 2 a.m.score all customerstomorrow's churn listwin-back emails

The Model Becomes a Service

The move itself is almost anticlimactic. The model file is copied to a server, and a small program is wrapped around it — a program whose whole job is to answer questions. Ask it "customer 4711?" and it runs the model and replies "churn risk 0.71". The asking and answering happen over an API — an agreed-upon way for one program to ask another program a question and get an answer back. That one sentence is all the plumbing this book needs; the point is what it buys. The model is no longer a file someone has to open — it is a service: always on, reachable by any part of Plateful's software, answering thousands of questions an hour without a human in the loop.

Notice what did not change: the model itself. Same numbers, same recipe, exactly as it left the tournament. Deployment moves the model into position; it does not make it smarter. Everything the model will ever know, it learned before this page began.

Two Serving Rhythms

There are two rhythms a deployed model can serve in, and the choice between them was made back in Topic 30 — the team just didn't know it yet. Real-time serving answers the moment it is asked: a payment-fraud model must score the transaction while the customer waits at checkout, in a fraction of a second, or it is useless. Batch serving answers on a schedule: run the model over everyone, all at once, and store the results for later use.

Which rhythm does churn need? Look at the action on the framing card: win-back emails, sent by the marketing team in the morning. Nobody is standing at a checkout waiting for a churn score. So the churn model runs as a batch job — every night at 2 a.m. it scores every active customer, and by morning there is a fresh list of who is at risk this week. The action dictates the rhythm, not fashion: a team that builds real-time serving for a nightly email list has bought a sports car to deliver newspapers.

Production Has Opinions

Here an analogy earns a page of its own. Winning the tournament is like winning a cooking competition with a prize recipe — the hard science is done. But now the dish goes on the menu, and it must be cooked four hundred times a night, fast, identically, by equipment that does not fall over during the Friday rush. Same recipe, entirely new discipline. That new discipline is what the word production means: software serving real users, at real volume, with real consequences when it stumbles.

Production's demands are concrete. Speed: a fraud check that takes ten seconds is a failed fraud check, however accurate. Load: Friday dinner rush multiplies requests, and the service must not buckle. And safe rollouts: a new model is not switched on for everyone at once — it first serves a small share of traffic, say 5%, while the team watches for trouble, and only then takes over (engineers borrow a mining term for this pattern and call it a canary release). None of this is modeling work, which is why a distinct role exists for people who carry models into production — Chapter 11 will name it when we map the field's jobs.

The Bridge to the Rest of the Catalog

One honest orientation note, because this is where the course touches the wider world of software. The churn service runs on the same rails as every other service: it lives on cloud servers — the rented, always-on computers that the Cloud from Zero course explains from scratch. It ships inside containers — a standard way to package a program so it runs the same everywhere, taught properly in the Docker course. And it reaches those servers through automated build-test-deploy pipelines — the craft of the DevOps course.

The point of naming them is what it tells you about ML: a deployed model is ordinary software with an extraordinary component inside. ML inherits the software world's infrastructure; it does not replace it with something exotic. When you are ready for that world, those courses are the path — this book's job was only to show you where the bridge is.