Part II of our series on AI-assisted software development
In the first part of our series, we looked at what a custom-built tool can do better than an off-the-shelf solution. Now for the other side of the equation.
First, to avoid giving the wrong impression: this is not a list intended to discourage anyone from building their own software. We see how AI tools help our customers improve efficiency and simplify staff scheduling and operational processes—and we think that is a good thing. Instead, this article focuses on the costs and responsibilities that are almost always missing from the initial estimate because they do not arise at the beginning, but later.
Building is the inexpensive part
Today, a tool can be built in a weekend. Operating it takes years.
In between, there are servers, backups and, at least once a year, a test to make sure that a backup can actually be restored if an emergency occurs. There are updates to the components used in the software and adjustments whenever something changes within the company. New colleagues need to be trained, and existing users need support when something does not work at the start of their shift.
All of this continues long after the custom software project has stopped being exciting. And it is precisely this part that is included in the price you pay to a provider such as CrewBrain.
When the person who built it leaves
Think back to the Excel spreadsheet with macros from Part I. In practice, a custom-built tool belongs to the person who created it. If that person leaves the company, moves to another department or is absent for an extended period, the business may be left with software whose inner workings nobody else understands.
AI may be able to explain the software to a successor—but it cannot take responsibility for it.
“It works” does not mean “it is secure”
As a software provider, this is the issue that has occupied us ever since powerful AI tools became available.
For us, however, security has never been an AI-specific topic. It has been a fundamental principle from the outset. Anyone managing data belonging to tens of thousands of people asks the same questions before releasing every new feature: Who is allowed to see this? Where is the data stored? What happens if something goes wrong?
This is not optional diligence. It is simply part of our responsibility as a software provider.
What AI has changed is not the principle, but the speed. Code is now produced faster than anyone can review it—and that is where the gap emerges.
This can also be quantified. Since 2023, Veracode has regularly tested the security of code written by AI models. Its March 2026 report found that although more than 95% of the code was syntactically correct, it was secure in only around 55% of cases. This rate has not improved significantly since testing began, even though the models have become considerably more capable in functional terms.
The weakest results concern precisely the types of vulnerabilities that are difficult to spot in a running system—for example, user input that can cause damage. This may be acceptable for an internal tool that does not contain sensitive data. It is far more problematic for a system with user accounts that may be accessible from the public internet and stores employee data.
Built quickly does not mean stable
In the 2025 DORA Report, 90% of respondents said they used AI at work, and more than 80% felt it made them more productive.
One relationship remains negative, however: the impact on stability. The sheer volume of AI-generated output leads to more incidents, particularly when safety nets are missing. These safety nets include automated tests, proper version control and, of course, immediate feedback when something breaks.
The report’s central conclusion is that AI does not fix a team—it amplifies what is already there.
A weekend project, however, does not usually have this safety net. This is not a criticism of AI or its use. It is simply an acknowledgement that successful AI adoption often depends on the environment in which it takes place.
The real issue: sensitive data
Software such as CrewBrain rarely contains harmless data that could just as well be public. It stores addresses, dates of birth, clocked working hours and often even photographs of identity documents or certificates.
When this data is stored by a provider such as CrewBrain, a data processing agreement defines who is responsible for what. With an internally developed solution, all responsibility remains within the company:
- The way data is protected must be documented internally and, if necessary, demonstrated.
- Requests for access, correction and deletion must be supported technically. A legally compliant deletion policy involves more than simply marking an item as deleted.
- In the event of a data breach, there is a 72-hour reporting deadline. Meeting that deadline first requires the breach to be detected. Large providers such as CrewBrain have logging and monitoring systems for this purpose. A solo weekend project probably does not.
The law does not stand still
The obligation to record working hours already exists in Germany and has existed at EU level for even longer. However, the exact form this obligation will take in the future remains unresolved. A draft bill reforming the German Working Time Act provides for electronic recording with staggered transition periods, but it has not yet been adopted.
This is only one of many examples. The minimum wage and its documentation, retention periods, temporary staffing regulations and requirements arising from collective agreements are all subject to change—sometimes gradually, sometimes substantially.
For us, keeping track of these developments is part of our daily work because we already have to do so for our users. Anyone building their own software takes on this task alone—not just once during development, but permanently.
Small details that become painful later
Finally, there are the issues that are not noticeable in the first version but add a little more work and expense every month.
Public holidays that differ between German federal states. Time zones during tours across multiple countries. No mobile reception inside venues. Who is allowed to see which information in the system—and how? A crew of hundreds trying to clock in simultaneously at 7 a.m. on a Saturday and overloading the server. A job deleted by accident that needs to be restored.
All of these problems can be solved. But each one takes a little more time.
Questions to ask before developing your own software
Rather than making a recommendation, we would prefer to offer a few questions worth considering before making a decision:
- How much personal data will ultimately be stored in the tool?
- Am I willing and able to accept responsibility if sensitive employee or business data is unintentionally exposed because of an error?
- What happens if the tool unexpectedly fails on the day of a show? Is it merely inconvenient—or also expensive?
- Who will continue maintaining it if the person who built it is no longer there?
- Who will handle compliance matters such as working time recording?
- Are my operational processes really so unique that standard software cannot cover most of them?
- Is there a budget for operating the software—or only for building it?
As a rule of thumb: the more personal data the tool contains and the more expensive an outage would be, the stronger the case for buying. The smaller the group of users, the stronger the case for building it yourself.
And quite often, the right answer is: both.
2 comments
Comments are closed.