“But that's a web framework!” – Why I develop automations with Django

Nov. 8, 2026 · 18 min read · Sensible digitalisation, From the workshop

When I tell people that I develop many of my automations with Django, I occasionally get asked:

“Why Django? Isn't that really a web framework?”

Yes, absolutely. But for me that is exactly one of its greatest advantages. When it comes to automation, many people first think of tools like n8n, Make or Zapier. They can connect different services and automate entire workflows, often without much programming of your own. I find such tools genuinely useful and use them myself.

However, in many of my projects I do not just want to move information from one program to the next. What interests me far more is how entire ways of working in a business can be mapped digitally and then automated. And for that I often need more than a sequence of individual actions. I need an application in which people can work, information is stored in a structured way and different processes are connected to each other.

This is exactly where Django shows its strengths for me.

Digitisation comes before automation

Let's imagine a cleaning company that cleans stairwells and other parts of buildings for various property managers. One property manager writes an email:

“The stairwell in building 12 was not cleaned on Tuesday.”

Now I could use an AI that reads this message and writes a friendly reply within a few seconds. Technically, that is no great challenge today. But what is the AI actually supposed to say? After all, it does not know whether anyone really was on site that Tuesday.

Maybe the job is on a timesheet. Maybe it was documented in an Excel spreadsheet. Perhaps the cleaner also sent a photo by WhatsApp. So the information may well exist already, but it sits in different places and is not easily linked together. And that is exactly a problem I come across again and again when looking at how businesses work.

Before we can sensibly automate processes, the information they need must first be reliably available and as structured as possible.

That is why, in our example, I would not even start by setting up an AI to answer complaints. I would first want to understand how the business actually works. How are jobs planned? How do employees document their work? Where does this information end up? And what happens when a client complains? Only then would I think about how we can map this process digitally.

Individual work steps become an application

My idea in this case would be one shared web application in which everyone involved can work, but with different levels of access and different functions. In the morning, the cleaner opens an overview of their planned jobs on their smartphone. There they can see which sites are coming up, which tasks have to be done and whether there is anything special to note. After cleaning, they tick off their checklist and can add a photo as proof if needed.

The office gets a different interface. This is where jobs are planned, employees assigned, open tasks checked and incoming complaints handled. Instead of being gathered from various spreadsheets, emails and chat histories, the information sits right there with the case in question.

And the property manager could get their own access too. There they see their sites, the jobs carried out and the corresponding proof, without access to the data of other clients, of course. So we have three different groups of users with very different requirements.

But they all work from the same data.

And nobody has to install complicated software for this. A browser on a smartphone, tablet or computer is enough. These are exactly the kinds of applications I like to develop, because they often solve several problems at once that were not necessarily seen as connected before.

Now we can start to really automate

Let's come back to our complaint. The property manager sends an email because a stairwell has supposedly not been cleaned. Our application can receive this message automatically and open a new case.

An AI analyses the content and suggests which site and which day it is about. The application then uses the existing data to check whether a job was planned and documented for that day. Maybe everything has been recorded in full and there are even photos. Maybe a proof is missing. Or no job was in fact documented.

The office sees the complaint together with the relevant information and can check the case. The application could even prepare a suitable reply already. After an employee has approved it, the necessary proof is compiled and the reply is sent. This saves time, reduces searching and means information no longer has to be painstakingly gathered from different sources.

But I would be far from satisfied with that. Because if we already know which jobs are planned and which have actually been documented, a very different question arises:

Why do we wait until someone complains at all?

Our application could regularly check whether planned jobs have remained undocumented. If a proof is missing, the office is alerted. Maybe the cleaning has simply not been confirmed yet, maybe someone has fallen ill, or a job really was forgotten. Instead of having to react to a complaint, the business can now take the initiative.

And for me, that is one of the most interesting aspects of such solutions. We are not just automating an existing work step; we can improve the whole process.

Why I like to use Django for this

Of course, some of these functions could also be built with other technologies. So why Django of all things? For me, it is above all the combination of a mature web framework, Python and the ability to build applications in a structured and modular way.

Data and how it connects

With Django's ORM I can define directly in Python which data our application should manage and how it is connected. In our example, that would be customers, sites, employees, planned jobs, checklists and complaints. A property manager looks after several sites. A site has many jobs. A job belongs to an employee and can contain various pieces of proof.

Relationships like these can be mapped cleanly in a data model. That may sound rather unspectacular at first, but it is the foundation for almost everything we want to automate afterwards. Because only when the application knows these connections can it reliably answer questions such as: Which employee was scheduled in building 12 on Tuesday? Was the job documented? Is there proof of it? And who needs to be informed if something is missing?

Users and permissions

Django already comes with user management as well as a system for groups and permissions. Building on that, I can define which functions a user may use and which information they may access.

The cleaner needs different functions from the office, after all. And a property manager may of course only see the data of their own sites. I have to develop and test such object-level access rules for each application, but Django already gives me a very good foundation for them.

Interfaces that fit everyday work

This point matters a great deal to me. An automation can be as technically impressive as you like. If the people who are supposed to work with it cannot get on with the application, it will be of little use. That is why I want to develop interfaces that follow the actual way of working.

The cleaner does not need extensive management software on their smartphone, just a simple overview of today's tasks and a quick way to document them. The office, on the other hand, needs considerably more information, filters and management functions.

With Django's template system I can create such interfaces directly from the existing data. In combination with tools like htmx, interactive functions are possible as well, without my having to develop an extensive JavaScript frontend every time. And that is exactly what I like: I can concentrate more on the actual application.

Many of the basics are already there

Another advantage is the number of functions Django already brings along. With the admin area I can, for example, manage data, often before the actual user interface is fully developed. Database migrations allow controlled changes to the data models. On top of that come functions for user authentication, forms, multiple languages, tests and various security mechanisms.

Of course, this does not automatically produce a secure and reliable application. That still takes clean implementation, the right configuration and appropriate tests. But I do not have to develop many basic functions myself first.

And then of course there is Python. Whether PDF processing, Excel files, image recognition, interfaces or AI: there are mature libraries for an incredible number of tasks. This lets me bring all kinds of functions together in one application without constantly switching between completely different technologies.

Start small and grow when needed

Not every application needs a large infrastructure from the start. If a small business needs, say, an internal tool for a single area of work, it would make little sense to set up several database servers, queues and background processes for it right away. That is why I like that with Django I can start comparatively simply and extend the architecture later.

From SQLite to PostgreSQL

For small applications, SQLite can be entirely sufficient. The database lives in a file, no additional database server has to be run and the effort stays manageable. Several users are generally possible with it as well. With many simultaneous writes, however, SQLite reaches its limits sooner.

For larger applications with several people working at the same time, I therefore prefer PostgreSQL. PostgreSQL offers extensive capabilities for concurrent processing, data integrity and querying more complex data. Django supports both databases, so large parts of the application code can be reused. A switch does of course have to be prepared and tested, but I am not tied to a particular size from the start.

Background tasks with Celery and Redis

A similar principle applies to tasks that do not have to be done immediately during a web request. If an employee creates an extensive report, processes several documents or starts an AI analysis, for example, they should not have to wait minutes for a response from their browser. I have such tasks run in the background.

For smaller applications, a simple database-backed queue can already be enough. When the requirements grow, I use, for example, Celery with Redis. This allows tasks to be distributed across different workers and several processes to run in parallel when needed. Recurring tasks are possible too, such as the daily check of all planned cleaning jobs.

What I like about this is the ability to start small and adapt the infrastructure to actual needs. I do not have to run the same complex architecture for every small customer project.

Develop once, use many times

This is in fact one of the areas I have been working on especially intensively of late. Because my goal is not simply to develop individual applications. I want to create a development process with which I can build, deliver and maintain custom software over the long term as efficiently as possible. For this I have built my own development and delivery environment.

An important part of it is reusable Django components. After all, I need certain functions in many applications. User management, permissions, document processing, notifications, imports or interfaces are not peculiarities of a single customer project. So why should I redevelop them from scratch every time?

Instead, I develop shared components that I can version, extend and reuse in different applications. The actual custom development can then concentrate more on the specific requirements and ways of working of the customer in question.

The application is individual. But I do not have to start from zero every time.

For me, that is a pretty decisive difference. Advances in AI-assisted software development in particular mean that new code can be written very quickly today. I think that is great and make intensive use of these possibilities myself.

However, I do not want to end up looking after a hundred different applications in which the same basic functions have been implemented a hundred different ways. That would make maintenance needlessly complicated in the long run. That is why I attach great importance to shared components, clear interfaces and an architecture that is as consistent as possible.

From development to operation

I have also largely standardised delivery. With Docker, the application and the services it needs can be run in containers. This lets me run software on different servers, for example on rented infrastructure or, where required, locally at the customer's premises.

My customer applications can be operated as separate instances with their own databases. Delivery and updates follow standardised procedures, so I do not have to set up a complete server environment by hand each time.

For me, this is an important part of the whole concept. Because I do not just want to be able to develop software quickly. I also want to operate it reliably afterwards and keep developing it over the long term. I describe more about the technical setup under Technology and approach.

Why I still do not develop everything with Django

For all my enthusiasm for this approach, Django is of course not always the best choice. If I only want to connect two existing cloud services, a web application of my own is often not necessary. Tools like n8n, Make or Zapier are excellently suited to exactly such tasks.

For simple tasks that are to run regularly, a small Python script is sometimes enough as well. And if I first want to find out whether a particular automation is of any use at all, a quickly built prototype may make more sense than a complete application.

A Django application does have to be developed, operated and maintained, after all. That causes effort and costs that have to match the actual benefit. So I do not regard workflow tools and custom applications as competitors. On the contrary. A Django application can, for example, communicate with n8n through an interface. That way the two approaches can be sensibly combined.

For me, what matters is not which tool happens to be popular. What matters is which problem I want to solve with it.

And now comes one of the most exciting points for me: what do we do with the data?

By this point we have already achieved quite a lot with our application. We have digitised job planning and documentation, brought information together in one central place and automated several work steps. But something else has happened along the way that I find particularly interesting.

Almost in passing, we have created a set of data that simply did not exist in this form before.

Let's stay with our cleaning company. Every documented job produces new information. We know, for example, when a job was planned, how long it actually took, what work was done and whether there were complaints afterwards. After a few months or years, some rather interesting insights can emerge from this.

From simple reports to better decisions

To begin with, we do not need any artificial intelligence for this at all. Even simple statistics can add a lot of value. Perhaps we find that certain sites regularly need more time than originally planned. Or that complaints occur particularly often when there is a longer gap between two cleanings. We may also see that certain tasks take considerably more effort depending on the season.

With information like this, the business can improve its planning, calculate quotes more realistically and spot problems early. That is already a big step forward from a situation in which most information is scattered across paper or individual spreadsheets. But of course we can go one step further.

Can we train our own AI models with this data?

Yes, in principle we can. And I find this possibility particularly exciting. Let's imagine, for example, that we want to predict as accurately as possible how long a particular cleaning job will take. For this we could use data from past jobs. How big is the site? What work has to be done? How often is it cleaned? How long did comparable jobs take in the past?

With enough good-quality data, we could train a model that uses this to estimate the likely time needed for new jobs. The application could then take these predictions into account directly when planning jobs. Of course, this does not have to be a neural network. With structured data like this in particular, classic machine learning methods can often deliver excellent results already. But the principle stays the same:

Our application no longer uses only fixed rules; it can use historical data to make predictions about future events.

A neural network for image recognition

Another example would be the photos our cleaners take to document their work. Suppose that, over a longer period, many pictures are taken of cleaned areas, waste containers or other regularly checked facilities.

With enough suitable and appropriately labelled images, we could train a neural network to recognise certain visible anomalies. Perhaps the model is meant to determine whether a waste container is obviously overflowing or whether a photo shows heavier soiling. The application could then automatically flag conspicuous images so that an employee can check them.

Of course, I would not rely blindly on an AI model for such decisions. Photos only ever show part of the picture, and automatic image recognition can make mistakes. But as additional support for quality control, something like this could certainly be interesting. And when you consider that our application was originally only meant to document cleaning jobs and make complaints easier to handle, that is quite an exciting development.

Not every analysis needs its own AI model

There is one point I would like to stress explicitly. Just because we collect data does not mean we have to train our own neural network. Often simple reports, understandable rules or classic forecasting methods are entirely sufficient.

And sometimes it makes more sense to have existing AI models work with the business's own data than to train a model yourself. What always matters is the benefit the solution in question actually delivers.

Training our own models also takes enough good and suitable data. In smaller businesses that is not always available, and data often has to be cleaned or prepared for training first.

Data protection also has to be considered from the start. Personal data in particular must not be used for AI training simply because it is technically available. That takes a clear purpose and a suitable legal basis.

That is why I would design the application as early as possible so that useful analysis is possible without collecting data unnecessarily. And that is another advantage of developing an application myself: when designing the data model, I can already think about which information could really be helpful later.

A small tool can become much more in the long run

When I look at this whole process, what I find most interesting is how it develops. We start with a very concrete problem. A cleaning company wants to document its jobs better and handle complaints more easily. For this we first develop an application that makes employees' daily work easier. Then we automate individual work steps.

And because the application continuously records structured data along the way, we can analyse it later and possibly even use it for learning systems. In the long run, a simple job log could become an application that supports planning, spots possible bottlenecks early and helps to keep improving the way work is done.

Of course, not every small project will one day need a complex AI system. But I find the mere possibility of developing an application step by step in this direction enormously interesting.

For me, that is the real appeal of combining custom software development, automation and artificial intelligence.

We do not just solve a single problem; we create a foundation on which further possibilities can emerge over time.

My conclusion

When I talk to a business about digitisation today, I am at first less interested in the programs they use than in how they actually work. Where is information entered more than once? Which tasks keep repeating? Where do employees have to painstakingly gather information? And which things only work because someone takes care of them every day? Especially in smaller businesses there are surprisingly many of these.

Modern development tools and AI are making it increasingly economical to develop custom software even for such individual problems. For me, Django is a versatile tool with which I can combine the digitisation, automation and later development of such processes in one application.

It is not about using as much technology as possible. Sometimes a simple database with a sensible interface is already an enormous improvement. Sometimes that later turns into an automation that saves several hours of work every day. And perhaps the data that has been built up will one day open up possibilities nobody thought of at the start.

That is exactly what excites me about custom software development: you start with a concrete problem from everyday work and can develop it step by step into something that goes far beyond the original task.

Are there processes in your business that take up too much time?

Perhaps at your business too, information is entered more than once, tasks are coordinated by hand or data is gathered from different programs. It does not always take a large software solution. Sometimes a small tool, an interface or a manageable automation is enough.

If you like, you can describe your process to me through my initial assessment. I will gladly look at what options there are and whether a custom solution makes economic sense for your business.

• Django
• Automation
• Python
• Celery
• PostgreSQL
• Docker

All posts