Your Model Works in a Notebook. That Is the Easy Part.
Part 1 of From Notebook to Production: the gap between a model that runs once and one that runs for real, and the five questions that define it.
Your model works in a notebook. You ran the cell, the accuracy printed, the chart looked good, and for a moment it felt finished.
It is not finished. It is barely started. A notebook is a demo you give to yourself, under perfect conditions, with data you have already seen, while you sit and watch. Production is a promise you make to other people: that the thing will work when you are asleep, on data it has never met, at a cost you can afford, and that it will fail in a way that does not hurt anyone. Those are completely different problems, and the gap between them is where most data-science work quietly dies.
This series is about crossing that gap. This first part is about seeing it clearly, because you cannot cross a gap you do not believe is there.
The notebook lies to you, kindly
The notebook is a wonderful place to think and a terrible place to judge whether you are done. It lies to you in three specific ways, and it does so gently, which is why it fools careful people.
It shows you a model that works once, and lets you feel that means it works. It shows you a model that works on data you already have, and lets you forget it will meet data you do not. And it shows you a model that works while you are watching, and says nothing about the three in the morning when it fails and nobody is there.
None of that is the notebook's fault. It was built to explore, and it explores beautifully. The mistake is treating the end of exploration as the end of the work. It is the end of the first quarter.
The five things production makes you answer
Here is the whole shape of the gap, as five questions a notebook never asked you and production will not let you avoid.
1. Serving: where does it actually live, and how is it called? A model in a notebook is a variable in memory. A model in production is a thing other systems can reach: an endpoint, a scheduled job, a batch process. Deciding which of those it should be is the first real engineering decision, and it depends entirely on who needs the answer and how fast.
2. New data: what happens when the world moves? Your model learned a pattern from the past. The world keeps going. Prices change, behaviour shifts, a new product launches, and the data arriving next month may not look like the data you trained on. A notebook never has to survive this. Production does, and pretending otherwise is how models rot silently while everyone assumes they are fine.
3. Monitoring: how would you even know it broke? This is the question that separates people who have shipped from people who have not. If your model started returning nonsense tomorrow, what would tell you? If the answer is "a user would eventually complain," you do not have a production system. You have an outage with a delay.
4. Cost and latency: can you afford to run it, and is it fast enough? In a notebook, compute is free and time does not matter, because it is just you. In production, every call has a price and a wait, and both are multiplied by everyone who uses it. A model that is a little too slow or a little too expensive per call is not a small problem at scale. It is the whole problem.
5. Failure: what happens when it is wrong, or down? It will be both, eventually. The question is whether that is a shrug or a catastrophe. A good production system has an answer for "the model is unavailable" and "the model is confidently wrong" that does not involve hoping neither happens.
Why I care about this more than the model
When I built the crop-yield model for Sierra Leone, the version that lived in a notebook was, honestly, useless. A number on my screen predicting a harvest helps no one. It only becomes useful the day it runs on its own, on free satellite rainfall data that arrives every month, and produces an early warning that a person deciding when to plant can actually read and act on, months ahead.
That is the entire difference between a research artifact and a tool. The research was the easy, satisfying part. Making it run reliably, on data that keeps arriving, cheaply enough that a ministry could afford it, so that its output lands in front of someone who can use it, that is the part that would decide whether any of it mattered. The model was the thesis. Production was the point.
The market is telling you this loudly
If you would rather hear it from data than from me: the Stanford AI Index 2026 found that the fastest long-term growth in AI job postings is not in building models. It is in the deployment skills, cloud platforms, scalability, and workflow management, the exact capabilities that turn a working model into a running system.
The field has more people who can train a model than people who can keep one alive in production. The scarce skill is the second one, and scarce skills are how careers are built.
What this series will cover
Over the next parts, we go through the gap one plank at a time: serving a model so other systems can reach it, handling data that drifts, monitoring so failures announce themselves, controlling cost and latency (including when to pay the reasoning tax and when not to), and designing for failure so that "wrong" and "down" are survivable. We will do it with the constraint that runs through everything on this publication: it has to work on a real budget, on hardware and power you can actually count on, because uptime is a feature and intermittent infrastructure is an input to your design, not an excuse.
Key takeaways
- A notebook proves a model can work once. Production requires it to work continuously, on unseen data, within a budget, and to fail safely.
- The five real questions are serving, new data, monitoring, cost, and failure. None of them is about model architecture.
- The scarce, valuable skill is deployment, not modelling, and the job market is paying for exactly that.
- Research is the thesis. Production is the point. A model nobody can rely on helps nobody.
- Start by shipping the model you already have. One reliable mediocre model teaches more than ten notebook-bound good ones.
What is one model you have built that never left the notebook? That is the one to start with.
Source: Stanford HAI, 2026 AI Index Report, Chapter 4 labour-market data (hai.stanford.edu/ai-index/2026-ai-index-report), for the finding that deployment-oriented skills show the fastest long-term growth in AI job postings.
Found this useful? Passing it on to someone who builds is the best way to help the publication grow.