Django development
Django decides a lot for you: how data is stored, how staff sign in, how the database changes over time, and a ready-made screen for administrators. That is a gift on a business system built around records and rules, and a straitjacket on one that turns out not to be. Knowing which you have is the whole decision.
01Capabilities
Four systems that age well on a framework with opinions
Django is the Python web framework, so this page is deliberately narrow: things served over the web with a database of records behind them. If your question is about Python more broadly, meaning data pipelines, machine learning or automation, our Python page is the right one. Four shapes cover nearly everything we are asked to do here.
- Operations
The back-office system a company actually runs on
Approval flows, operations consoles and the internal tools nobody markets, including the administrative side of an LMS. The ready-made admin screen gives staff something usable in week one, which is a real schedule advantage and a real trap if you ship it as the finished product.
- Interfaces
An interface over data whose rules are worth keeping
A published interface in front of a database whose constraints are load-bearing. Serialization, permissions and paging are solved problems here, so the engineering is the contract you publish and the query patterns underneath it, which is where platform integration work usually lands.
- Catalogue
Structured content that editors manage and customers read
The catalogue, pricing and fulfilment back end behind an e-commerce operation. The way the data is modelled is the product in this shape of system, and getting it wrong is expensive to unwind once there is a year of real data sitting in it.
- Upgrades
Projects two or three supported releases behind
Dependency lists nobody dares touch and habits from a version of Python that has been retired for years. Getting to a supported release in ordered steps is the job, and it is legacy modernization rather than a rewrite. We do that work under an ISO 27001:2022 certified information-security management system.
02Fit
When the conventions stop paying for themselves
Django wins where the data is relational, staff need an interface early, and the conventions spare you an argument about structure. It loses in a few shapes that reach us often enough to name, and it usually loses to a decision that was never really about Django. Five of the six rows below end somewhere other than a Django project with us.
| Your situation | What we recommend |
|---|---|
| A rule-heavy business system, data that belongs in tables, and staff tooling needed early | Use DjangoThe conventions, the way database changes are managed, and the admin screen are worth more than any speed comparison you will read. |
| The real question is Python generally: pipelines, models, automation, nothing on the web | Different pageOur Python page covers that side, and the framework is not the decision you need to take. |
| Live updates, streaming, or a service whose job is holding thousands of connections open | We argue againstSupport for that exists but sits on top of a design that assumes one thing at a time, so Node.js fits better. |
| Your team is a .NET or Java shop with nobody who writes Python | We argue againstBuild it in ASP.NET or Java. A framework nobody on staff can maintain is a liability dressed as a preference. |
| Mostly pages and editorial content, with very little business logic behind them | Not a buildWordPress or a published static site will cost less to build and far less to run every month afterwards. |
| An existing project several releases behind, and slow to change | Do not rewriteUpgrade one supported release at a time. A rewrite here is the expensive way to buy what an upgrade and a pass over the queries deliver. |
Scope
What we own here is the way the data is modelled and everything that follows from it. That means the shape of the database, the path from one release to the next, and how the system behaves once there is real volume in it. It also means whether the next developer can read the code. We run that work under an ISO 27001:2022 certified information-security management system, alongside ISO 9001:2015. unicrew has been building software since 2012, with 100+ senior in-house engineers across six countries. Where the answer is to upgrade rather than rebuild, that is what you get, even though rebuilding would have been the larger engagement.
Django's conventions are the reason a small team can carry a large application, and they are also the thing people fight when the product stops fitting the admin. The moment you are writing more code to escape the framework than to use it, that is worth naming out loud rather than absorbing quietly. Usually it means one part of the system wants to be its own service, not that the framework was wrong.
Yaroslav HavrylivSenior Engineering Manager, unicrew03Delivery
Reading a project through its history of database changes
Four steps, in this order. On a project somebody else wrote, the first two are where the actual information is, and where a bad estimate usually gets made.
- Read the data model and its change logThe database and the record of how it got that way are the real documentation. Squashed steps, skipped steps and columns that were clearly added by hand all tell you something about the project before a single screen has been opened.
- Pin the environment, then test what earns moneyA rebuildable environment first, because on older projects the set of dependencies is the thing nobody can reproduce. Then tests over the behaviour that pays the bills, driven through the screens where the internals resist being tested directly.
- Upgrade one supported release at a timeWarnings about things due for removal are treated as work, never as noise, and never a single jump to the newest version. In practice Django itself is rarely the blocker: it is two or three abandoned add-ons, and deciding what replaces them is the real planning.
- Fix the query patterns before anything elseLoops that hit the database once per row, missing indexes, and screens that quietly fetch half the table to show ten items. Most complaints about speed here resolve at that layer rather than in caching, extra workers or a bigger server.
04Stack
What a records-and-screens application runs on
The decisions that usually arrive with a project like this, each with its own page if that is the one you are actually taking.
05Questions
Asked before an upgrade gets funded
Answered the way we would answer them live. If yours is not here, it is a good first message.
Yes, and on an existing project it is often the right shape, because your people know the domain. What we will not do is hand over developers and walk away from the design. The data model and the upgrade plan get reviewed by an architect outside the delivery team, and the work goes through the same QA practice as our own projects. Capacity is managed teams; an outcome is custom software development.
This one if you have something served over the web with a database of records behind it, because then the conventions are most of what matters. Our Python page if the work is data engineering, machine learning or automation, where the interesting decisions are about libraries rather than frameworks. Plenty of systems are both, so start wherever the risk is and the call will cover the other.
Django when there is a data model, an admin surface and a permissions model to build, because you get all three on day one. FastAPI when the service is a thin layer over something else and needs none of that. The failure we see is teams choosing FastAPI for a system that grows a data model anyway, then rebuilding Django badly, one utility at a time. For conventional products the closer alternative is Ruby on Rails.
Yes, and it is a large part of the work we take on here. One supported release at a time rather than a jump to the current one, because the warnings in between are the map. Expect the abandoned add-ons to be the real cost rather than the framework, and expect us to want tests over the paths that earn money before the first upgrade lands. That sequence is what keeps the application shippable throughout.
Often, yes, and it is worth naming rather than working around. That screen is built for people who already understand the data, so it exposes everything and guards very little. Once outside users are in it, the questions become permissions, audit trails and mistakes that are hard to reverse. The usual fix is to keep it for staff, and build the small number of screens outsiders actually need.
A scoping call with an engineer. For an existing project we ask for read access to the repository beforehand, because the data model and the change history tell us more in twenty minutes than a long call will. What comes back is written: what we would do first, what we would leave alone, and where the risk sits. Most engagements start within two to four weeks.
Three shapes, and which fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based and quoted per project, and we only offer it after the first read, because a fixed number on a system nobody has opened is a guess. Team extension is billed monthly per engineer, and the rate depends on the seniority mix, so it is quoted rather than listed.
Pinned to a release that stopped getting security fixes?
Tell us what the application does and which version it is stuck on. You will get an engineer's read on the upgrade path or the build, including the parts we would leave alone.