Turning a trained churn classifier into a FastAPI service that other software can actually call.
A few months ago, I tried to challenge myself to undertake a journey to transition from a data analytics background to data engineering. So far I’ve built a total of two impactful real-world projects that actually taught me something useful. I built a GitHub ETL pipeline that extracts GitHub repositories and loads them into a SQLite database — this ran on a schedule using GitHub Actions. I also built an RSS pipeline that extracts articles from RSS feeds and stores them into a Kestra database — orchestrated by Kestra to run on an hourly schedule.
Now that I’ve understood ETL to a point, I wanted to try something new. I wanted to keep practicing all I’ve learned in the past whilst building something new. I had always been fascinated by the field of machine learning, but never actually had the courage to step in because I thought it had complex math. Not anymore.
Recently, I built a churn prediction model for a fictional telecom company I am calling Northline Mobile (P.S. I’m using a fictional company because I understand things best with real-world scenarios). I provided it with data from 7043 customers, telling it whether they had signed up for a 1-year contract or month-to-month plans, length of customer, monthly charges, add-ons, etc. Furthermore, I told it who eventually left Northline Mobile. I cross-validated the model with customers it had not seen yet.
It achieved 81% accuracy. This taught me everything that goes into building a model. Obviously I didn’t understand all the complex code, because I prefer intuitive drag and drop interfaces rather than complex code. But I understood the essential building blocks of building a model; I’ll explain further below with a simplified architecture.
So building this model felt like a win from a machine learning perspective; my model worked.
But there was still one problem: it was still not really useful.
Assuming a Northline employee who needed a prediction comes to me, I would have to open Jupyter, load the right notebook, run the cells in the correct order and make a manual call to predict_churn(). Yeah, the model exists, but I was the only one that knows how to use it. No one else at Northline could just send information on a customer to the model and retrieve a prediction and it could not speak to any other application either.
This article will be covering this.
I recently learned that there is a difference between having a model and having a service.
If a model just sits in a notebook only the person who built it can use it. But making it a service makes it possible for everyone to use it, other teams, apps, dashboards and systems that do not need to know or care how the prediction is made.
It turns out building the machine learning model was the easiest part, but making it useful is another crucial element worth exploring.
What "Done" Meant Before the API
Here's roughly what building the model looked like:
That’s pretty much it. Nothing too fancy.
By the end of that, I had a trained churn classifier, a preprocessing pipeline that cleaned and encoded the raw data, and evaluation numbers I was comfortable with (more on those numbers shortly, they're not perfect and I'm not going to pretend they are).
But like I said. Assuming Northline's retention team builds a dashboard, and they want it to flag at-risk customers automatically. Their dashboard can't reasonably open my Jupyter notebook and run my cells. It needs something else entirely. Something like this:
That's the shift this article covers. One quick disclaimer, though: this isn’t a FastAPI tutorial. FastAPI is simply the tool I happened to use to expose the model as a service. The interesting part, at least for me, was figuring out what that service should actually look like.
The Boundary I Actually Needed
The real question wasn't "how do I put FastAPI around my model." It was "what should the boundary between my software and my model actually look like."
I had two options. Full fidelity or something more simplified that only involves training the model on a handful of data. I settled on full fidelity: this means that the API accepts every raw field Northline's other systems would realistically have about a customer, the same columns as the original dataset, not some simplified subset. A request would typically look like this:
And the response is deliberately small:
I have to point out something real quick though. That risk_level field isn't something the model produces. The model only outputs a raw probability. But a raw 0.31 isn't something a retention rep can act on at a glance, so I added a simple bucket: below 0.3 is Low, 0.3 to 0.6 is Medium, above that is High. Those thresholds are a starting guess, not something I derived statistically, and I want to be upfront about that rather than pretend they're more rigorous than they are.
This is the boundary. Input schema, output schema, what's required, what's rejected. Once I'd actually thought this through, the endpoint itself was almost the easy part.
Preparing the Model for Life Outside the Notebook
There's a step between "request arrives" and "prediction comes back" that's easy to underestimate: the raw JSON coming in looks nothing like what the model actually expects. Here’s what the journey typically looks like:
It’s worth keeping in mind that the API can't invent its own version of preprocessing. Whatever happened to the data during training has to happen, identically, at inference time. For instance, if training scales tenure and MonthlyCharges a certain way, and the API scales them differently, or forgets to scale them at all, the model is being handed numbers it's never seen the shape of before. But the fascinating thing is that it won't give you an error, it'll just quietly guess wrong.
So to prevent this issue, I built one preprocessing.py
, imported by both the training script and the live API.
There's a specific bug this caught, however. My binary-encoding function looked like this during training:
That's fine when training, because the training data has a Churn column, the actual answer. But a live request obviously doesn't have Churn in it. That's what we're trying to predict. Running this function unmodified against a request would crash looking for a column that was never going to exist. The fix was small, just check the column's actually present first, but it's exactly the kind of thing that only shows up once you try to run training-time code at inference time.
Building the FastAPI Layer
Here's how the project ended up structured:
Two things are worth explaining about this layout. First, train.py
lives at the project root, outside app/. app/ is specifically the code that runs the live service. Training isn't part of the service, it's a separate process that produces the artifacts the service depends on. Second, train.py
reaches into app/ to reuse preprocessing.py
, not the other way around. The service doesn't know or care how it was trained. It just needs the same preprocessing logic.
Loading the Model Once
One decision that seems obvious in hindsight but wasn't something I thought about until I nearly got it wrong: where do you load the model?
The wrong way is loading it inside the /predict function itself, so every single request reads the .pkl files off disk again. That's slow, and it's wasteful for no reason.
The right way is loading it once, when the module is first imported:
By the time the API is actually serving requests, the model is already sitting in memory, ready to go. This is a small detail, but it's the difference between an API you built and an API you built like it's actually going to be result = predict_churn(customer.model_dump()) return resultused.
Designing /predict
With the model loaded once and preprocessing shared with training, the actual endpoint ended up small:
That smallness is intentional. All the actual logic, preprocessing, loading, prediction, lives in model.py
and preprocessing.py
. The route function's only job is to receive a validated request and hand it off. I didn't want business logic creeping into what should be pure HTTP plumbing.
Behind that route, predict_churn
runs the request through the same steps training used, including one detail that took me a minute to understand: a single request can only ever produce one value per one-hot encoded category. Training data might generate four PaymentMethod dummy columns across thousands of rows, but one customer's request can only be one payment method. So before prediction, I reindex the request's columns against the exact list the model was trained on, filling anything missing with zero:
Without that, a single request's column layout wouldn't reliably match what the model expects, and scikit-learn would either error or silently misalign features. This is the sort of detail that never shows up when you're testing on a full dataset, only when you send the model exactly one row at a time.
Testing It Like Software
Getting a 200 OK in Swagger UI wasn't the finish line I thought it'd be. The more interesting question was what happens when the input isn't clean.
I sent a request with tenure missing entirely. The API rejected it before the model ever saw it:
I sent "gender": "female", lowercase, instead of the expected "Female". Rejected again, with the exact reason:
Neither of these ever reached predict_churn(). That's the point. The schema isn't just documentation, it's an actual gate. Bad input gets a clear, specific error back, not a confusing model failure three layers deep, and not a silently wrong prediction because the model tried to make sense of something it was never trained to see.
When It Finally Felt Like Software
Before, getting a prediction meant:
with Jupyter open, the right cells run in order, the right variables still sitting in memory from earlier in the session.
Now it's POST /predict
from anywhere. A curl command in a terminal. A request from a different application entirely. Someone who has never seen my code, never installed pandas, never heard of scikit-learn, can still get a churn prediction out of this model. That's the actual transformation. The model didn't get any smarter. It became something other software could use.
What Still Isn't Solved
Here's the honest part. Sure, the model works and the API works. But it only works on my laptop.
If a Northline engineer tried to run this exact project on their own machine, there's no guarantee it would work. Maybe their Python version is different. Maybe they don't have Anaconda installed the way I do. Maybe a package version mismatch breaks something silently. Right now, "it runs" is really shorthand for "it runs on my machine, under my specific setup, and I'm not fully sure which parts of that setup actually matter."
There's also no way to run this in the cloud yet. It's not reachable by anyone outside my own network. If my laptop is off, the API is off.
I'm not solving any of that here. That's genuinely the next article. What I wanted to nail down first was making sure the application itself, the boundary, the contract, the validation, was solid before adding infrastructure on top of it. Adding Docker and a cloud deployment to something with a shaky foundation just means the shaky part is now harder to debug.
What I Learned
A working model isn't automatically a usable one.
Good evaluation metrics tell me the model learned something useful. They don't tell me that someone else can actually send it data and get a prediction back. Turning a model into something people can use requires another layer of engineering.The API is a contract, not just a wrapper.
I initially thought the API would mostly be a thin layer around the model. In practice, deciding what a request should contain, what the API should reject, and what it should return turned out to be just as important as calling the model itself.Inference is its own engineering problem.
Getting a model to predict inside a notebook is relatively straightforward. Making those predictions reliably through an API introduces a different set of concerns. Preprocessing has to match training exactly, the model should be loaded once rather than for every request, and even something as simple as how a single request is shaped can matter.Building locally first exposed the real problems early.
The Churn column bug, the reindexing issue, and even the convergence warning I ran into during training had nothing to do with the cloud. They were problems in the application itself. Finding them locally was much better than discovering them after adding Docker, EC2, and a deployment environment on top.A clear boundary makes deployment easier later.
I don't know exactly what Part 2 will throw at me once deployment enters the picture. But I do know that the application has a clear shape now: data comes in, it gets validated and prepared, the model makes a prediction, and a structured response goes back out. Whatever breaks next, at least it won't be because I never defined what the API was supposed to do.
Now I Had a New Problem
I started this article because the model worked but wasn't useful. By the end, it's useful, at least to me. Anyone on my own machine, hitting localhost:8000, can get a real prediction back, complete with validation that catches bad input before it ever reaches the model.
But that's still the whole limitation. My laptop is the only place this exists.
In the next part, I'm taking this exact service and putting it inside a container, then deploying it to AWS. A few assumptions that have been invisible this whole time, about my environment, my file paths, and my local Python setup are about to become impossible to ignore.