Why I still reach for Flask

This site runs on Flask. So do a surprising number of the internal tools I’ve built. I rewrote my old “getting started with Flask” post because it read like documentation, and documentation is not what I actually believe about Flask. What I believe is closer to a design principle: reach for the smallest tool that solves the problem, and add weight only when the problem demands it.

What Flask is, and isn’t

Flask is a microframework. Out of the box it does routing, templating, and request handling, and then it gets out of your way. It doesn’t ship an ORM, an admin panel, an opinion about your project structure, or a build step you have to fight. For a lot of people that sounds like less. In practice it’s less in your way.

The framing I use: Django (and the JavaScript equivalents) hand you a furnished house. Flask hands you a good foundation and good tools. If you’re building the standard thing, the furnished house is great. If you’re building something specific — an internal tool with a weird auth requirement, a data app, a site like this one — the foundation lets you build exactly what’s needed and nothing else.

Why it keeps winning for the work I do

• It starts in minutes. A useful app is a single file. That matters more than it sounds: the cost of trying something is near zero, so I try more things.
• It’s honest about size. Flask doesn’t pretend a 200-line tool and a 50-route product are the same problem. You add structure (blueprints, an app factory) when you’ve earned the complexity, not on day one.
• The ecosystem is right there. Need auth, mail, a database? Add the one extension that does that. You assemble what you need instead of inheriting what you don’t.
• It deploys like a normal Python process. No build pipeline ceremony to put a small thing in front of users. For internal tools shipped fast, that’s the whole game.

The honest caveats

Flask’s freedom is a loaded gun if you’re undisciplined. Nobody enforces your structure, so a Flask app can rot into spaghetti faster than a framework that fights you. The answer isn’t a heavier framework — it’s the discipline the framework assumes you’ll bring: a sane layout, tests, and not hand-wiring things you’ll regret. (That’s the same lesson as everything else I write about: the tool exposes your process; it doesn’t replace it.)

The actual point

Flask isn’t special because it’s Python or because it’s fast to demo. It’s special because it embodies a way of working I trust everywhere: start small, delete what you don’t need, and only add weight when the problem actually asks for it. Most problems ask for far less than people think. Flask lets you give them exactly that.