Python and Django development from a team that has shipped it for years

Why we build business systems on Django

Every web framework can produce a working application. The differences show up later, in how much of the boring but essential work you have to build yourself, how safe the defaults are when a developer is tired, and how much it costs to upgrade three years from now. Django wins on all three for the kind of software we are usually asked to build.

It arrives with sensible protection against the common web attacks already switched on. It has a proper migration system, so changing the database as requirements evolve is a controlled operation rather than a series of hand written statements that somebody forgets to run on the live server. It has a user and permission model that suits almost every business application. It has an administration interface that gives clients a usable back office within days rather than weeks.

Just as importantly, Django has been maintained for many years by a large community with a published release and support policy. That matters commercially. An application written today has a documented upgrade path for a long time, and there are thousands of developers who could maintain it if you ever needed somebody other than us. Fashionable frameworks frequently cannot offer either of those things.

Django REST Framework for interfaces

When an application needs to feed a mobile app, a partner system or a separate front end, we use Django REST Framework. It handles serialisation, authentication, permissions, filtering, pagination and throttling in ways that other developers recognise immediately, and it gives us browsable documentation that makes integration work far less painful for whoever is on the other side.

Our own platform uses this pattern extensively. One Django backend defines the business rules once, and the web interface, the Android application and the iOS application all consume the same API. That is why the three stay consistent instead of slowly drifting apart, which is a common and expensive failure in projects where each platform reimplements the logic.

Celery and Redis for everything that should not block

Any application that grows will eventually need to do something slow. Sending thousands of notifications. Producing a large report. Processing an uploaded file. Calling an external service that takes eight seconds on a bad day. Doing that work while a user waits is the fastest way to make software feel broken.

We use Celery with Redis to move that work into background processes. The user clicks a button and gets an immediate response, while the heavy lifting happens where nobody is watching. The same infrastructure runs scheduled tasks, such as nightly summaries, reminder messages, overdue alerts and data housekeeping. Redis also serves as the cache, which is usually the single fastest improvement available to a sluggish application.

MySQL and the data underneath

Django works comfortably with MySQL, which is our usual choice for durable storage. We design schemas properly, using constraints and foreign keys rather than trusting the application layer to behave, and we choose indexes based on the queries the system will genuinely run rather than adding them everywhere and hoping.

The part that separates experienced Django work from inexperienced Django work is usually query behaviour. It is very easy to write code that looks clean and quietly issues one database query per row in a list, which is fine with twenty records and catastrophic with twenty thousand. We watch for those patterns during development rather than discovering them when a client calls to say the page has stopped loading.

What Django projects we take on

We build new Django applications from scratch, we extend existing ones, and we take over projects where the previous developer has moved on. Rescue work is common enough that we have a standard approach to it, starting with a written assessment of the code, the database and the server so you know exactly what condition your system is in before deciding what to do.

We also handle Django upgrades, which many companies postpone until their version is unsupported and the jump becomes frightening. Handled as a series of small planned steps, an upgrade is routine. Left for five years, it becomes a project in its own right, and the security exposure in the meantime is real.