2024 was a busy year for me. My clients really kept me on my toes with lots of fun and exciting R&D projects. Nearly all of them were built on the same stack. Some are internally facing, processing about 1.5 million messages asynchronously per day, some are customer facing, with a few hundred requests per second peak, but overall still nothing too crazy. I am sure they will get a bit more traction in 2025. Additional to that we worked on a non profit side project that will likely go online in January.
I obviously did not write all these projects from start to finish by myself. For the first four to eight weeks I worked mostly alone on these projects. But during this time there were still other engineers to brainstorm, figure out the API for integration points, get some help with customer specific domain questions and have a project or product manager track down external information that were needed. I was just the lucky one to write code all day and I got to push these things to production for the first time.
Which is also the point when we usually brought in more people to add features, hand over the project to them or simply make sure the bus factor is not one. Software engineering is rarely a solo activity and mostly a team sport. Even if only one person writes the code.
Even with the amount of different people that interacted with these projects, there is one thing they all have in common: the tech stack.
That is all. Now, we can argue about web scale all day long. And you will find a definition of web scale where this stack will fall apart. But it will take a good long while. Using Postgres as backend for Django-Q2 might not be the fanciest option. Or the best. But it kept complexity low and it works. (Very well I might add.) The system will surely outgrow a $60 Postgres DB one day. When this day arrives a Redis instance will be spun up and business continues as usual.
There were obviously some discussions around the stack. Should we not use the right tool for the job - where the definition of „right“ means a tool excelling at a singular part of the overall system but potentially having drawbacks on others? Maybe we should build it in house. What about five libraries stitched together being a more “modern” and “more performant” stack? All good arguments.
I was moving fast with all my customers. The teams had various degrees of experience across different stacks and technologies. Most knew Python. So jumping between projects is fairly straightforward if you know the stack already and all apps look the same. Additionally all three libraries and Postgres are very well understood at this point. You can find a ton of information online. LLMs could “learn” from a large set of open source and worst case you have to read the documentation. Which for all three libraries / frameworks is excellent.
“The right tool for the job” is not just answering which technology allows to achieve a goal the fastest during runtime. Sure, there are projects where you have to push your stack, potentially use specific languages that lend themselves well to a specific problem space. But that is an exception, not the rule.
Another thing that was helpful was the batteries we could fall back to. “We have a slight change in requirements, could we have these four data points editable through a web interface?” Five lines of Django admin code later and we were good. Shoutout to mozilla-django-oidc. It just works and is quick to set up, while meeting corporate SSO requirements. I would not let a whole team of untrained people run wild in Django admin. But one or two stakeholders and a PM after a short introduction? Any day of the week.
Do not take this as a “write everything in Django” post. There are more often than not limitations or requirements making Django a suboptimal solution. I am currently building a project in Go for this exact reason. (I also shipped two Go applications this year.)
Take this post as a “when you think Django is slow, old and not flexible, think again” kind of post. I could have stitched together FastAPI with SQLAlchemy and an SPA on top. But this would have taken far longer. Onboarding would have taken longer. And we might have found some surprises along the way because it is a less know, less documented stack. And Django works well for APIs. Or async workflow engines. Or regular web apps, especially once you sprinkle in some HTMX.
Django is not perfect. There is still a lot of work to do. There are parts that might need to be brought to the 2020s, their age really shows. And for some projects it will be too slow, too inflexible or just not a good fit. Just do not dismiss it outright. More often than not it can be a viable choice. And you get so much more than “just a framework”.
From a business perspective there are so many more things that go into a technology choice than just the tech. Onboarding, hiring and consultant pool, longtime support, existing documentation and much more. As engineers we often like to pretend these are all an afterthought. They are not. And one day you will have build your perfect app in Zig or Nim and management will task you to hire a team to take over or add more hands to the project. Not as fun or easy as we often pretend it will be.
For 2025 I am looking forward to playing around with Django Ninja. Not just because the cool name, but also because Pydantic support is actually a selling point to me. The documentation looks good, the project has been around for some time and the async support can be useful. I am curious seeing if nogil will change the Python landscape or if it will be a story as disillusioning as async.
No matter what your 2025 stack will look like: happy hacking!