Django development

In my experience it is rarely the framework. It is one of these:

• The domain model. The schema is the decision with the longest shadow: it outlives the views, the templates and usually the frontend framework. Time spent here is the cheapest time in the project.
• Isolation between customers. If you are building software several organisations use, "we filter by tenant in the queryset" is one forgotten filter() away from showing one customer another customer's data.
• The boring correctness. Money, invoices, VAT, discount interactions, timezones. Nobody demos these and every one of them is a support ticket when it is wrong.
• The integrations. Payment providers, ERPs, mail, whatever the client already runs. These are where estimates go wrong, because the work is not writing the client — it is what happens when the other system is down, slow, or returns something its documentation says it never returns.

None of that is exotic. It is just the part that is still there after the framework choice stops being interesting.

Test-driven where it earns its keep — which means the domain logic, the money and the permissions, not every template. The point is not coverage as a number; it is being able to change the thing in eighteen months without holding your breath.

Small commits, deployable continuously, and migrations that are reviewed like code rather than generated and hoped over. If a design decision has a tradeoff worth knowing about, you will hear about the tradeoff and not just the recommendation.

• A schema and a domain model written down and explained, not just implemented.
• A test suite around the logic that would be expensive to get wrong.
• An API other people can build against, if you need one.
• A codebase that reads like Django rather than like a framework invented on top of it — so the next developer is productive in days rather than months.

Bakeup is multi-tenant SaaS for micro-bakeries — an online shop plus production planning — built on django-tenants, so each bakery gets its own instance with data separated at the database level rather than by a query filter. Running since 2022.

Land Matrix publishes data on large-scale land investments. The existing platform was PHP; I rebuilt it as a Django application with PostGIS and was part of planning and shipping the relaunch in the first quarter of 2017.

Agile Strategy Map is a Django REST backend with a React frontend, taken from prototype to a first usable version, including designing the API.

Lifelessons is an online course shop on Django Oscar with Mollie payments, and custom work for the client's own payment types and discount rules — the boring correctness, in practice. Live since 2019 and still mine to maintain.

Django is a good default for this class of problem because the unglamorous things are already solved and solved conservatively: the ORM and migrations, authentication and permissions, the admin, and a security record maintained by people who publish what they got wrong. You are not the first person to need any of it.

The other reason is boring and more important: Django has been around long enough that hiring for it is possible, and its long-term support releases mean a project can sit for a year without becoming unsupported. For software that has to be alive in five years, that matters more than throughput benchmarks.

Where I would not reach for it: a realtime-first product where nearly everything is a websocket, or a service whose whole job is one CPU-bound computation. Django can be made to do both and something else would do them more naturally.

Get in touch and describe the problem rather than the solution — what the software has to do and who for. If a schema already exists, that is the most useful thing you can send.