What a Django build hands your own staff on day one

A Python framework that arrives with the decisions already made

Django is free, open-source software a team builds on, not a product anybody buys a licence for. It's written in Python, and the phrase its own community uses is batteries included: it ships with the parts almost every web application needs, rather than leaving a team to pick them one at a time.

That list is longer than it sounds. A way to describe your records in Python and have the database tables follow. Accounts, passwords, groups and permissions. Forms and validation. Security defaults that are on before anyone has thought about security. And an administration interface, generated from that same description, which your own staff sign into and use.

You still pay for hosting, a database and the people who write the rest. What you don't pay for is a team spending its first month choosing between four ways to do each of those things.

It behaves this way because it was written in a newsroom

Django came out of a newspaper. It was built at the Lawrence Journal-World in Kansas, where a small web team produced new sections of the site on newsroom deadlines, and it was released publicly in 2005.

That origin explains most of how it behaves. When the same handful of people build a staff directory, then an election results section, then a database of local restaurants, the repeated part gets obvious fast: describe the records, get screens for editing them, decide who's allowed in, publish. Django is that pattern factored out and given away.

It's looked after now by the Django Software Foundation, a non-profit, with a published release schedule and a security process. Nobody can change the terms underneath you, because there's no vendor in the arrangement. It's named after the guitarist Django Reinhardt, and the D is silent.

The generated admin is why a lot of teams pick it

This is the part that decides more Django builds than anything technical does. Register your records with the admin and Django produces working screens: lists with search and filters, forms to add and edit, a log of who changed what, and permissions set per type of record.

So on the day the first version goes live, somebody who has never opened a terminal can sign in and manage the data. For internal tools and back-office systems that's weeks of work nobody had to quote for.

There's a limit, and Django's own documentation is blunt about it: the admin is meant for trusted people inside your organisation, not as the interface you build a product around. It's shaped like a filing cabinet, because that's what it's for. If the plan is for customers to use it, somebody is building a real interface anyway, and that build hasn't been quoted.

Where it stops: it has opinions, and arguing costs more than agreeing

Django decides how a project is laid out, how records are described, how a request is handled and how the pieces talk to each other. Accept those decisions and work moves quickly, including the work of whoever you hire next, because one Django project looks like every other one.

Go against them and you pay twice. Once to build the exception, and again every time the framework updates and somebody checks it still holds. The teams that struggle with Django usually aren't doing something hard. They're doing something ordinary in an unusual way. Rails and Laravel make the same bargain in other languages, so if your proposal names one of those instead, the questions here still apply.

Two other ceilings are worth knowing before a quote surprises you. Django grew up handling one request at a time. It has since added support for the newer continuous style, but plenty of the packages around it still assume the older one. So anything live, chat, presence, a screen that updates while you watch, is separate machinery alongside Django rather than something the framework does itself.

And it doesn't draw your front end. Django renders pages well enough by itself, which is fine for anything that behaves like a website. If the product has to feel like an application, that's a second body of work in a browser framework, talking to Django across a boundary somebody maintains.

Who has to be around afterwards

Django needs Python developers, which is a large and ordinary labour market. You can hire, put the same job to three firms, and replace one when a relationship ends. Two years in, that matters more than any feature comparison did at the start.

It also needs somewhere to run: a server, a database, and somebody keeping both current. Django designates some releases as long-term support and keeps patching those for years after the next one lands, so the upgrade is something you put in a calendar rather than discover. Somebody still has to put it there.

Because your own staff manage the records, the day-to-day stops queuing behind a developer. You need one for changes to how the thing works, not for changes to what's in it. That's a real difference in what year two asks of you.