Why we build business software on Django
An unfashionable framework choice, explained in commercial terms rather than technical ones, including the cases where we would recommend something else.
Clients usually say they do not care what their software is written in, and in one sense they are right. Nobody buying a booking system cares which framework produced it. The reason the choice matters is that it decides what your third year costs, whether you can hire somebody else, and whether a security update is routine or alarming.
What you are actually buying with a framework
Every business system needs the same foundations. User accounts. Login and password handling. Permissions. Protection against the common web attacks. A way to change the database structure safely as requirements evolve. An administrative interface for the people who manage the system. A way to write and run scheduled tasks.
None of that is specific to your business. All of it has to exist before anything useful can be built on top. The commercial question is simply whether you are paying somebody to build those foundations or whether they arrive included, and Django arrives with all of them.
That is the entire argument in practical terms. When we build with Django, the budget goes into the part that is specific to your company. When a team assembles the same capability from separate libraries, a meaningful share of the money goes into rebuilding foundations that already exist elsewhere, and into maintaining that assembly afterwards.
Security defaults matter more than security features
Every framework can be used securely by a careful developer on a good day. What separates them is what happens on a bad day, when somebody is tired and working to a deadline. Django is deliberately built so the safe route is the easy route, with protection against the common categories of attack switched on by default rather than requiring the developer to remember.
For a business, that is a risk reduction you cannot easily audit but which shows up in the absence of incidents. It also means a project inherited by a different developer later is less likely to contain the categories of mistake that lead to a breach.
The administration interface, which is genuinely worth money
Django includes an automatically generated administration interface for the underlying data. It is not a substitute for a properly designed application, and we do not hand it to clients as their main system, but it is available from the first week of a project.
The practical benefit is that internal staff can view and correct data immediately, long before the polished screens exist. It also means the awkward one off administrative tasks that every system eventually needs can be handled without building a screen for each of them, which quietly saves a great deal over the life of a project.
Migrations, or how to change a database without fear
Requirements change, which means the database structure changes, and doing that safely on a live system holding real data is one of the genuinely difficult parts of software maintenance. Django migrations make schema changes versioned, ordered and repeatable across environments.
The alternative, which we have inherited more than once, is a folder of hand written statements and a colleague who remembers which ones were run on the production server. That situation is how data gets damaged, and it is entirely avoidable.
Longevity and being able to replace us
Django has been maintained for many years by a large community with a published release and support policy. Python is one of the most widely taught and used languages in the world. Together that means a system written today has a documented path forward and a large pool of developers who could maintain it.
We consider that a feature we are selling rather than a risk to us. A client who can replace their supplier is a client who stays because they want to. Choosing a niche framework would make us harder to replace and would be a worse deal for the people paying.
Where Django is not the answer
It is not the right choice for everything and pretending otherwise would undermine the argument. A simple brochure website does not need it. Applications whose value lies in a highly interactive interface, such as a design tool or a live collaborative editor, are better served by a JavaScript application, and we build those where the requirement genuinely calls for it.
Very high volume systems with unusual data shapes sometimes justify different storage technologies, and specialised domains occasionally have mature platforms that would be foolish to reimplement. Our position is not that Django is universally correct, only that for records based business systems with roles, workflow and reporting, which is most of what companies actually need, it is the choice that costs the least over ten years.
Evidence rather than assertion
Our own platform is the test of this position. QuranRecord runs on Django, serving more than a million page views a month across a web interface and two native mobile applications that consume the same Django REST Framework API. It has been through multiple framework upgrades and continues to be maintained by a small team. That is what the boring choice buys.
Wondering what your project should be built with?
Describe what the software needs to do and we will tell you what we would use and why, including the cases where our usual answer is the wrong one.