Jupyter in production: when the workflow needs to change

Welcome back to OR-Path!

Field Notes is about applying Operations Research inside real organizations, where data, software and people shape how decisions get made.

Jupyter is a useful starting point for learning optimization. I would also keep it in the toolbox at work, provided its role matches what the operation needs.

So let’s get straight to it.

Consider João, an analyst planning routes for a small fleet. He has spreadsheets, BI tools and access to Colab. He builds a notebook to compare routing scenarios, reviews the results and hands a plan to the team.

João is using an optimizer as an analytical tool. He does not need to deploy a service just to make that useful. For this kind of work, or implementing a model from class, a notebook is a reasonable place to start.

Jupyter has no fixed CPU or RAM allowance. With local execution, the available resources come from your computer; remote hosting can provide different capacity.

Free Colab has variable resource availability and runtime limits, so a single machine specification would be misleading. Check memory use and solve time with representative instances before deciding whether the environment fits.

Notebooks can be automated with tools such as Papermill. An LLM is not required to execute them programmatically.

For me, the turning point is operational dependence: must the plan arrive every morning, even when João is away? Then I would ask:

Operations Research systems need those responsibilities to be explicit. A notebook can remain part of the solution, supported by a more dependable execution process.

Use notebooks to learn, test ideas and support analysis when that workflow fits. As operational requirements grow, revisit how the optimizer runs and who maintains it. That transition deserves its own Field Note.