Why I Still Reach for Django When a Project Has to Ship

Every few months a client asks why I'm not building their backend on whatever framework is currently on the front page of Hacker News. It's a fair question, and my answer is usually the same: because the project has a deadline, and Django has already solved the six things that would otherwise eat my first two weeks.

Authentication is the clearest example. A new project needs signup, login, password reset, session handling, and permissions before it does anything a user would pay for. In Django that's an afternoon. Everywhere else it's a decision tree. Which auth library, which session strategy, how to hash, where to put the reset tokens. Every branch of that tree is a place to get security subtly wrong.

The admin is a real feature, not a demo

The Django admin gets dismissed as a toy, and that's a mistake. On most of the projects I've delivered, the admin *is* the internal tool. The client needs to correct an order, refund a payment, or fix a typo in a product description, and they need to do it without messaging me. Handing them a working admin on day three changes the entire shape of the engagement, because I stop being a bottleneck for routine data edits.

It also gives me a place to look when something breaks in production. Before I open a shell, I can see the actual rows involved in whatever the client is describing.

Migrations are the part people underrate

Schema changes are where side projects go to die. Django's migration system isn't glamorous, but it gives you a reviewable, ordered, reversible record of how the database got to its current shape, and it works the same on my laptop as it does on the server. When a deploy goes wrong at 11pm, knowing exactly which migration ran and how to unwind it is worth more than any performance benchmark.

Where I don't use it

None of this makes Django universal. If the job is a handful of endpoints wrapping a model, FastAPI is a smaller, sharper tool and I'll use it. If the product is mostly rendering and the data layer is thin, Next.js on its own is plenty. This site is exactly that.

The point isn't that one framework wins. It's that on a fixed budget with a real launch date, the framework that has already made the boring decisions for you is usually the one that gets you there. Novelty is a cost, and it's a cost the client pays.

Written by Anmol Rajput, a freelance software developer building backends and AI features with Python, Django, and Next.js.