Why Django, and when not to use it

Before you write a line of Django, it is worth knowing exactly what you are choosing and, just as importantly, when you should choose something else. Django is one of the most productive ways to build a database-backed web application that exists — but it is a specific tool with a specific shape, and using it for the wrong job is how teams end up fighting their framework instead of shipping. This lesson is the honest case for Django, and the honest case against it.

What Django actually is

Django is a batteries-included web framework for Python. "Batteries included" is the whole pitch: where many frameworks give you a router and leave the rest to you, Django ships, on day one, with an ORM (talk to your database in Python, not SQL), an automatic admin interface, a full authentication system, form handling, a templating engine, security defaults, and a migration system that versions your database schema. You assemble an application from parts that are already there and already designed to work together.

The mental model to hold: Django has an opinion about how a web application should be structured, and following that opinion is where the productivity comes from. It is called an MTV framework — Model (your data), Template (your HTML), View (the code that connects them) — and we will meet each in turn. Fighting the opinion is possible but rarely worth it.

The head start, made concrete

The value is easiest to see by listing what you do not have to build. Imagine a clinic wants a system to manage patients and appointments — the application we build across this course, called Nidaan. With Django, on the first afternoon, you get:

A database layer without writing SQL. Define a Patient as a Python class; Django creates the table, and you query with Patient.objects.filter(city="Pune") instead of hand-written SQL.
An admin panel for free. Register your models and Django generates a complete, secure web interface where clinic staff can add and edit patients, appointments and reports — no frontend code. For an internal tool, this alone can be most of the product.
Authentication that works. Login, logout, password reset, password hashing, sessions — done, and done correctly, which matters enormously for anything holding real people's data.
Security defaults on by default. Protection against SQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF) and clickjacking is on out of the box. You have to actively disable these to be insecure, which is the right way round.

For a small team — a startup, an agency, a two-person clinic-software project — this is an enormous head start. You spend your time on the thing that is actually specific to your problem, because the generic 80% is already built and battle-tested by thousands of production sites.

What Django is genuinely good for

Django is at its best when your application is database-backed, content- or data-heavy, and needs the standard web-app machinery:

Internal tools and admin systems (the admin panel is unmatched here).
Content sites, marketplaces, booking systems, dashboards, SaaS products.
Anything with users, permissions, forms, and a relational database — which is most business software.
A backend that also exposes a REST API to a mobile app or a separate frontend (via Django REST Framework, which this course covers).

If your project looks like "users log in, do things with data stored in a database, and see results" — Django is very likely the fastest sound way to build it.

When not to use Django — the honest part

A course that only tells you what a tool is for leaves you to discover its limits on a real project, at the worst time. So, plainly, reach for something else when:

You are building a mostly-static site or a blog with no real application logic. A static-site generator (or plain HTML) is simpler, faster and cheaper to host. Django is overkill for a brochure site.
Your application is a real-time system — live chat, multiplayer, streaming, thousands of long-lived connections. Django can do async now (this course covers it), but Node.js or Go, or a dedicated websocket layer, are often a more natural fit for connection-heavy real-time work.
You need a tiny, single-purpose microservice or a quick API with almost no data model. A lightweight framework like FastAPI or Flask has less to learn and less to carry; Django's machinery is weight you are not using.
The frontend is the entire product — a heavy single-page application where the server is a thin API. You might still use Django (or DRF) for the API, but the interesting work is in the frontend framework, not here.
Raw, extreme performance per request is the hard constraint. Django trades a little runtime speed for a lot of developer speed. For most business software that is exactly the right trade; for a latency-critical hot path, a compiled language may be warranted.

None of these are Django "being bad". They are Django being a batteries-included, database-centric web framework — brilliant for that, unnecessary or ill-fitting elsewhere. The engineers who get the most from it are the ones who know which projects it suits.

Where Django sits next to what you know

You already know Python — Django is written in Python and you write your application in Python, so the language is not new; the framework's structure is. If you have used Flask, the difference is philosophy: Flask gives you a minimal core and you choose every component; Django gives you a curated, integrated set and asks you to use them its way. Flask is a kit of parts; Django is an assembled machine you customise. Both are excellent — Django's bet is that for most database-backed applications, the assembled machine gets you further, faster, and with fewer security mistakes.

This course assumes Python. If you are shaky on Python itself — classes, decorators, virtual environments, the standard library — take the Python Complete Foundation course first. Learning Python and Django simultaneously is the classic way to end up unsure which half of what you are typing is the language and which is the framework.

Check your work

What "batteries included" means. Django ships with the ORM, admin, auth, forms, templating, migrations and security defaults built in and designed to work together — you assemble, rather than source, the parts.

What MTV stands for. Model (data), Template (HTML), View (the code connecting them) — Django's opinion about how a web app is structured.

The concrete head start. A database layer without SQL, a free admin panel, working authentication, and security defaults on by default — the generic 80% of a web app, already built.

What Django is best for. Database-backed, data- or content-heavy applications needing standard web-app machinery — internal tools, SaaS, marketplaces, booking systems, and API backends.

When to choose something else. Static sites (use a generator), real-time/connection-heavy systems (Node/Go), tiny microservices (FastAPI/Flask), frontend-dominated SPAs, and latency-critical hot paths.

Django versus Flask. Flask is a minimal kit of parts you assemble yourself; Django is an integrated machine you customise — Django's bet pays off for most database-backed apps.

Practice

Write down three applications you might build. For each, decide honestly whether Django is a good fit, and name the deciding factor.
List the batteries-included features and, for each, name what you would have to build or source yourself if the framework did not provide it.
Find a real product you use that is (or could be) database-backed with users and forms. Sketch what its Models might be — you are already thinking in Django's shape.
Read Django's own "overview" page and note one capability this lesson did not mention.
For the Nidaan clinic system, argue in three sentences why Django suits it — and name one part of a clinic product for which Django would not be the right tool.

Official documentation

Django — Overview — The project's own summary of what it gives you.
Django documentation — home — The reference you will live in; bookmark it.
Django at a glance — Models, views and templates in a few short examples.

Next: starting a project the right way.