The 6 Python Libraries I Install Before Writing a Single Line of Business Logic

There’s a moment every developer knows.

You’ve just created a new project folder. Virtual environment is set up. You open your main.py file and it's staring back at you — completely blank, full of possibility, slightly intimidating.

Most developers dive straight into business logic at this point. They start building the actual thing. And three weeks later they’re doing one of two things: either frantically retrofitting logging into a codebase that was never designed for it, or debugging a production issue with absolutely no visibility into what went wrong because they never set up proper error handling.

I’ve been that developer. More than once.

Now I have a ritual. Before a single line of business logic gets written, six libraries get installed. Every project. No exceptions. Each one has earned its place through at least one painful production lesson that I’d rather not repeat.

Here’s the full breakdown.

1. Pydantic — Because Trusting Your Data Blindly Is How Bugs Are Born

Let me describe a bug I spent six hours debugging two years ago.

An API was returning a field called user_id. Sometimes it was an integer. Sometimes — for reasons the third-party API documentation did not mention, because of course it didn't — it was a string. My code assumed it was always an integer. It wasn't. Everything downstream broke in ways that had nothing to do with where the actual problem was.

Six hours. For a type mismatch.

Pydantic is the library that makes that entire category of bug impossible.

It gives you data validation through Python type hints. You define what your data should look like — field names, types, constraints, defaults — and Pydantic enforces it at runtime. If the data coming in doesn’t match what you declared, it fails loudly and immediately at the boundary where the bad data entered your system. Not six function calls later. Right there. With a clear error message that tells you exactly what was wrong.

What it handles for me on every project:

• Validating all incoming API payloads before they touch business logic
• Enforcing configuration schema so misconfigured environments fail fast
• Serializing and deserializing complex nested data structures cleanly
• Documenting what data looks like just by reading the model definition

The fact that repositioned this library in my mind: FastAPI — one of the most popular Python web frameworks in the world right now — is built entirely on Pydantic. When a framework that millions of developers use chooses a validation library as its foundation, that’s not an accident.

The thirty seconds it takes to define a Pydantic model has saved me hours of debugging on every significant project I’ve built since I started using it.

2. Loguru — Because print() Is Not a Logging Strategy

I’ll be honest with you about something slightly embarrassing.

For longer than I should admit, my “logging strategy” was print() statements. Strategically placed. Descriptively labeled. Completely useless in production because they don't include timestamps, log levels, file names, line numbers, or any of the context you desperately need when something breaks at 2am.

Python’s built-in logging module is the correct answer to this problem. It is also, genuinely, one of the most annoying standard library modules to configure. Handlers, formatters, filters — it works, but setting it up properly takes more boilerplate than it should.

Loguru makes logging what it always should have been.

One import. Zero configuration required to get started. Instantly you have timestamps, log levels, file and line numbers, color-coded terminal output, and stack traces that actually show you what went wrong instead of just where it went wrong.

And when you need more — file rotation, log compression, custom formatting, async logging, filtering by level — it’s all there. Just not shoved in your face before you need it.

What I configure in every project:

• Console logging during development with full color output
• File logging in production with automatic rotation at 10MB
• Separate error log that captures only warnings and above
• Contextual logging that includes request IDs for tracing across services

The production moment that made this non-negotiable: The first time I had a production bug with zero logs to go on — just a user saying “it stopped working” with no further context — I understood viscerally why logging is infrastructure, not an afterthought.

Loguru makes sure I never have that feeling again.

3. python-dotenv — Because Hardcoding Secrets Is a Career-Limiting Move

Let me tell you what happens when you hardcode an API key directly into your source code.

You push to GitHub. Maybe it’s a private repo and nothing happens. Maybe it’s a public repo and within four minutes — and I mean that literally, there are bots scanning GitHub commits in near real-time — someone finds it and starts making API calls on your dime.

I’ve seen this happen to developers I respect. It’s not a beginner mistake. It’s a moment-of-laziness mistake that anyone can make.

python-dotenv removes the temptation entirely.

It loads environment variables from a .env file into your application's environment at startup. Your secrets live in a file that goes in your .gitignore. Your code references os.environ.get('API_KEY') instead of a hardcoded string. The actual value never touches your codebase.

Simple. Effective. The kind of thing you set up in five minutes and never think about again.

What it manages in every project:

• API keys for every external service
• Database connection strings
• Environment-specific configuration like debug mode and log levels
• Feature flags that differ between development and production

The broader principle this library enforces: Code and configuration are different things. Code belongs in version control. Configuration — especially secrets — does not. The moment you internalize this distinction, you stop making an entire class of mistakes that can range from mildly embarrassing to genuinely catastrophic.

python-dotenv is the library that makes this principle effortless to follow.

4. Rich — Because Your Terminal Deserves Better Than Plain Text Walls

This one gets pushback sometimes.

“It’s cosmetic.” “It doesn’t affect functionality.” “It’s not something you need before writing business logic.”

All technically true. All missing the point.

Rich is a Python library for rich text and beautiful formatting in the terminal. Tables, progress bars, syntax-highlighted code output, formatted tracebacks, panels, markdown rendering — all of it, in your terminal, with zero effort.

Here’s why it goes in before business logic.

When you’re building a data pipeline and you can see a Rich-formatted table showing exactly what’s been processed, how many records succeeded, and what failed — you catch bugs faster. When your script’s progress bar shows you it’s been stuck on the same record for forty-five seconds, you know immediately something is wrong. When your error tracebacks are syntax-highlighted and formatted clearly, you spend less time parsing the error and more time fixing it.

Developer experience during development is not cosmetic. It directly affects how fast you build and how quickly you spot problems.

What Rich handles in every project:

• Progress bars for any long-running data processing task
• Formatted tables for displaying structured output during development
• Beautiful tracebacks that are actually readable under pressure
• Console logging output that’s scannable instead of a wall of text
• Status spinners for async operations so you know things are actually running

The underrated benefit nobody talks about: When you’re demoing something to a non-technical stakeholder in a terminal window and your output is clean, formatted, and readable — it lands differently than raw text output. Perception matters.

Rich is the library that makes your work look as good as it is.

5. Tenacity — Because APIs Fail and Pretending Otherwise Is Expensive

Here is something every developer learns eventually through a production incident.

External services fail. Networks hiccup. Rate limits get hit. Databases time out under load. Third-party APIs return 500 errors for reasons that have nothing to do with you and everything to do with their infrastructure having a bad Tuesday.

The naive approach is to make the API call and crash if it fails. This works perfectly in development where everything is local and happy. It fails constantly in production where the real world is involved.

The correct approach is retry logic with exponential backoff. Wait a moment, try again. Wait a bit longer, try again. Give up after a reasonable number of attempts and fail loudly with context.

Tenacity makes this a decorator instead of a hundred lines of retry boilerplate.

You decorate the function that makes the external call. You specify how many times to retry, how long to wait between attempts, what exceptions should trigger a retry, and what should happen when you give up. That’s it. The function now handles transient failures gracefully without you writing a single line of retry logic.

What I wrap with Tenacity on every project:

• Every external API call without exception
• Database connection attempts during startup
• File system operations on network-mounted drives
• Any operation that depends on infrastructure I don’t control

The number that changed how seriously I take this: Studies on large-scale distributed systems show that a significant percentage of failures are transient — meaning a simple retry would have succeeded. Without retry logic, those transient failures become user-facing errors. With Tenacity, they become invisible.

The goal isn’t to pretend failures don’t happen. It’s to handle the ones that don’t matter without bothering your users or your on-call engineer.

6. Pytest — Because Code Without Tests Is Just a Hope and a Prayer

I know what some of you are thinking.

“I’ll add tests later.”

You won’t. Nobody does. “Later” is where tests go to die. The longer you wait to add tests, the more coupled your code becomes, the harder testing gets, and the more intimidating the test suite feels to start. The only version of “add tests later” that actually works is when “later” means the same afternoon.

Pytest goes in before business logic because tests should be written alongside code from the beginning. Not after. Not “when the feature is done.” Alongside.

Pytest is the testing framework that removed every excuse I used to have for not writing tests. The syntax is clean. The output is readable. The fixture system is powerful without being complicated. The plugin ecosystem covers every edge case you’ll encounter — async testing, coverage reporting, mocking, parameterized test cases.

What my baseline Pytest setup includes on every project:

• Unit tests for every pure function as it gets written
• Integration tests for every external service interaction
• Fixtures that set up and tear down test state cleanly
• Coverage reporting so I know exactly which code has never been tested
• Parameterized tests for functions that need to handle many input variations

The compounding benefit that took me too long to appreciate: Tests aren’t just about catching bugs. They’re documentation. They’re the living proof of what your code is supposed to do. Six months later, when you’ve forgotten why you made a particular design decision, your tests tell the story.

And when you need to refactor something, a solid test suite is the difference between a confident afternoon and a terrifying week of hoping nothing breaks.

The Install Command I Actually Run

Every new project. Before anything else.

pip install pydantic loguru python-dotenv rich tenacity pytest

Thirty seconds. Six libraries. An entire category of future problems that simply won’t happen.

That’s the trade.

Why This Ritual Matters

There’s a version of software development where you figure out what you need as you go. It feels fast at the start. It feels very slow later, when you’re retrofitting structure into a codebase that was never designed for it.

There’s another version where you spend thirty seconds at the beginning installing the infrastructure that every serious project needs, and then you write business logic on top of a foundation that’s actually solid.

I spent enough time doing the first version to know I prefer the second.

These six libraries didn’t make it onto my list because they’re popular or because someone recommended them in an article. They made it because each one of them has a specific, painful memory attached to it. A bug that took too long to find. A production incident that didn’t have to happen. A lesson that cost real time and occasionally real money.

The best kind of library is one that makes a whole category of mistakes impossible.

Every single one of these does exactly that.

If this saved your next project from at least one future headache — follow for more. I write about the Python tools, patterns, and decisions that actually matter when you’re building things that need to work in the real world.