From Script to Production: What Python Tutorials Don’t Teach

You've finished the tutorial. You've built the to-do app, understood list comprehensions, and maybe even trained a small machine learning model. You feel good. You feel ready.

Then you try to take your script and actually deploy it somewhere — and it falls apart.

This is the gap that almost nobody talks about. Python tutorials are great at teaching the language. They're terrible at teaching what it actually means to write production-grade software. Here's what they skip.

1. Environment Management Is Non-Negotiable

Tutorials tell you to run pip install requests. They rarely explain why this is a catastrophic habit in the real world.

When you install packages globally, you're on a collision course. Project A needs numpy 1.21. Project B needs numpy 1.26. Your system can only hold one. Now add a production server running five different services, and you have a nightmare.

The answer is virtual environments — isolated Python installations per project. Tools like venv, conda, or the increasingly popular uv let each project carry its own dependencies. And requirements.txt (or better yet, pyproject.toml) ensures that whoever runs your code next — including future you — gets the exact same setup. If you're not managing your environments, you're not writing production code. You're writing a ticking time bomb.

2. Your Script Needs to Be a Package

Most tutorials teach you to write app.py and run it with python app.py. That's fine for learning. It's a mess for anything real.

Production code should be structured as a proper package — with an __init__.py, a src/ layout, and a pyproject.toml that defines your project's metadata and dependencies. This structure unlocks testing, importability, and installability. The moment your project grows beyond a single file, flat structure becomes a liability. Good packaging is the foundation that everything else — CI/CD, testing, deployment — is built on.

3. Errors Will Happen. Plan for Them.

Tutorials usually show you the happy path. The API returns data, the file exists, the database is up. Real software lives in the unhappy path. Production code needs to handle exceptions deliberately, not just except: pass (which is one of the worst things you can write in Python). It means understanding the difference between an error you can recover from and one you can't. It means logging what went wrong with enough context to actually debug it later.

Which brings us to logging. print() statements are for learning. logging is for production. The logging module gives you severity levels, timestamps, and the ability to route output to files, monitoring systems, or both — without changing a single line of business logic.

4. Configuration Does Not Belong in Your Code

Tutorials hardcode everything. The API key is in the script. The database URL is a string literal. The debug flag is True.

This is fine until the day you commit that file to GitHub and inadvertently publish your credentials to the world. It happens constantly, and it's entirely preventable. The right approach is to separate configuration from code. Environment variables are the standard mechanism — your code reads os.environ.get("DATABASE_URL") rather than a hardcoded string. Libraries like python-dotenv make this easy for local development, while proper secrets management (AWS Secrets Manager, HashiCorp Vault, etc.) handles it in production. The rule is simple: if a value would need to change between your laptop and a production server, it doesn't belong in your source code.

5. Testing Is How You Stay Sane

You've probably heard about testing. You might even know what pytest is. But tutorials almost never show you why testing matters until you've personally experienced the horror of breaking something you didn't know was connected to something else.

Unit tests verify individual functions in isolation. Integration tests check that components work together. The point isn't to achieve 100% coverage as a vanity metric — it's to give yourself the confidence to change code without terror.

Start with testing the code that would hurt the most to get wrong. Write tests before you refactor. Run them automatically before you deploy. Once you have a test suite you trust, you'll wonder how you ever shipped software without one.

6. Type Hints Are Not Optional Decoration

Python is dynamically typed, which tutorials often present as a feature: no need to declare types, just write code and go. This is true. It's also a footgun at scale.

Type hints — added via Python's typing module and enforced by tools like mypy or pyright — let you annotate what types your functions expect and return. At runtime, Python ignores them. But your editor and your CI pipeline don't, and they'll catch an enormous class of bugs before they ever hit production.

More importantly, type hints are documentation that can't go stale. When you come back to a function six months later, knowing that it takes a list[str] and returns an Optional[dict] is infinitely more useful than a vague comment.

7. You Need to Think About Concurrency

Tutorials write code that does one thing at a time. Real applications often can't afford to.

If you're building a web service, you need to handle multiple requests simultaneously. If you're doing I/O-heavy work — reading files, calling APIs, querying databases — synchronous code leaves performance on the table. Python gives you several tools here: threading, multiprocessing, and asyncio, each suited to different problems. Understanding the Global Interpreter Lock (GIL), knowing when to use async vs. threads vs. processes, and writing code that doesn't race itself are skills that take time to develop — but you can't ignore them if you want code that performs under real load.

8. Observability: If You Can't See It, You Can't Fix It

When something breaks in production, you need to know three things: what broke, when it broke, and why. Without proper observability, you're debugging blind. Observability has three pillars: logs (a record of what happened), metrics (numerical measurements over time — response latency, error rates, memory usage), and traces (a way to follow a single request through a distributed system).

Tutorials don't cover any of this because it's operational context, not language syntax. But a Python application without observability isn't really a production application — it's an educated guess.

9. CI/CD: Stop Deploying Manually

If your deployment process involves SSH-ing into a server and running git pull, you are one typo away from an outage. Manual deployments are slow, error-prone, and not reproducible.

Continuous Integration / Continuous Deployment pipelines (GitHub Actions, GitLab CI, CircleCI) automate the steps between "I pushed code" and "that code is running in production." They run your tests, lint your code, build your artifacts, and deploy — automatically, every time.

This isn't just a "nice to have." Once you've worked with a proper CI/CD pipeline, going back to manual deploys feels like navigating without GPS.

10. Code Style and Linting Are Team Infrastructure

Tutorials produce code that works. They rarely produce code that a team can maintain. Tools like ruff, flake8, and black enforce consistent formatting and catch common mistakes automatically. They eliminate entire categories of code review comments ("you have an unused import on line 14") and let reviewers focus on logic instead of style.

If you're working alone, this is still worth doing — your future self reading six-month-old code will thank you. If you're working with a team, it's essential. Agreed-upon style is how you reduce cognitive overhead and make the codebase feel coherent.

The Real Gap

None of these things are particularly glamorous. There's no "Introduction to CI/CD" tutorial that goes viral because it's intrinsically exciting to learn. But this is the gap between "I know Python" and "I can ship production software." The good news is that none of it is insurmountable. These are learnable skills, and you don't need to adopt all of them at once. Start with environment management. Add a linter. Write a few tests. Add logging. Each step makes your code more trustworthy, more maintainable, and more professional.

The tutorial got you here. The rest of the journey is yours.