Part I of our series on AI-assisted software development.
Two years ago, when an event company said, “We’ll build it ourselves,” that was usually the end of the discussion. Someone would suggest it, everyone would nod, the numbers would be calculated—and, because of the cost, the company would ultimately opt for an off-the-shelf or subscription-based solution after all.
Today, however, it is the beginning of a discussion—and quite often, the beginning of a working tool.
We are increasingly seeing this in our own conversations. A prospect decides against CrewBrain because they have built their own solution. A customer asks us about our API because they want to connect CrewBrain to their custom-built CRM. These are still isolated cases, but just a few years ago they would hardly have been possible—at least not for these reasons.
That is why this series is dedicated to the question: build or buy? We want to explore the arguments on both sides. In this first part, we look at what has changed and where building your own solution may be the better choice.
What has changed
It is not as though nobody programmed their own solutions in the past. Almost every company that has been around for more than a few years has an Excel spreadsheet with macros hidden away somewhere that is effectively an application. Or a functioning Access database that nobody has touched since 2011 because the person who built it is no longer with the company.
What has disappeared is the barrier to entry. Today, someone who understands business processes but has never written a line of code can use modern AI tools to build something functional over a weekend. Not merely a few clickable screens, but an application that runs on a server, has a login and can store data.
This should not be underestimated. The person who best understands how scheduling works within a company is not the developer, but the scheduler. Until now, that knowledge had to take a detour through a requirements document, a software provider and a product roadmap. Today, it can flow directly into the software.
Why this is happening faster in the event industry than elsewhere
The trend spans all industries, but it finds particularly fertile ground in ours:
The processes really are different. There is not a great deal of overlap between the workflows of a rigging company, an exhibition stand builder and a concert agency. Anyone developing software such as CrewBrain for all three must keep it flexible and broadly applicable. However, that also means it may not fit every company’s day-to-day operations perfectly.
Exceptional cases are more likely to be genuinely exceptional in this industry. In many sectors, companies consider themselves special cases when, ultimately, they are not. In our industry, however, there are so many different billing models alone that it is virtually impossible for a single software solution to cover every one of them completely—even though we are already getting very close ;).
The final 20% is what matters most. Standard software covers the majority of requirements well. The rest is often handled through workarounds or makeshift solutions. This is precisely where custom-built software comes in.
Finally, ours is a DIY industry. Anyone who solders their own adapters and builds their own flight cases is unlikely to hesitate when it comes to building their own scheduling solution.
Where custom-built software is better
As software developers, we could of course present a list of risks at this point. But first, let us look at the areas in which a custom-built tool can outperform an off-the-shelf solution—including CrewBrain.
A 100% fit: The software uses the same names and terminology as the company itself. There is no need to adapt to unfamiliar terms, no fields for processes that do not exist and no menu items that nobody in the company ever uses. Genuine niche requirements—such as a custom report—can be incorporated directly.
Speed: A requirement can become a solution within a few days or sometimes even a matter of hours. A professional software provider often cannot match that pace. When we develop a feature, we develop it for everyone. That means weighing up different requirements, creating configuration options, testing compatibility with the existing product and training our support team. This is the price of ensuring that the feature ultimately works for tens of thousands of users—but from the outside, the process can sometimes seem slow.
Building a tool also helps clarify a company’s own processes. Before developing a solution, you first need to understand exactly which workflows the software is supposed to represent. We have worked with companies that realised during this process that three different people had three different ideas of how the same scheduling process worked. That insight alone can sometimes be almost more valuable than the tool itself.
Our light-bulb moment
Although our first instinct might be to view a home-grown solution with a certain degree of suspicion, we quickly realised that a custom-built tool can also provide us, as a software company, with valuable insights.
When you ask people what they need from software, they tell you what they think they need. Their custom-built tool, however, shows you what they actually use. After it has been in operation for a few months, you can see which feature is opened every day and which was built once and then left to gather dust.
Until now, we have had virtually no access to this kind of information unless customers contacted us with detailed feedback. For privacy reasons, we do not track user behaviour within our software.
So when a prospect or customer tells us that they have built their own solution, our first reaction is curiosity.
This leads to our sincere request: if you have built something yourself, we would be delighted if you showed it to us. It may reveal something we could add to CrewBrain or something that is currently still too complicated.
In Part II, we will look at the other side of the equation: What does a custom-built tool cost in its first, second or third year—and why is “it works” not the same as “it is secure”?
1 comment
Comments are closed.