A few weeks ago, I built myself a little app. Not because I wanted to take over the job of our developers or suddenly get back into the day-to-day business of coding. But out of curiosity - and for a very practical reason. Our budgets were previously managed in an old internal system that was increasingly inflexible. It was difficult to map changes, it was cumbersome to use and in the end it was clear that we needed something new. So I asked myself: how far can I get myself today if I work with modern tools like Cursor that help me with AI-supported programming?
The result was a budget overview app that has become amazingly useful for me. But the experiences along the way were even more exciting. I was never a developer myself, but I worked with various programming languages at school and during my training and have been a technical product owner for many years. I was only ever able to program in a very rudimentary way - and that's exactly why it was exciting to get back into it myself after a long time and see how the possibilities have changed.
As soon as you start to translate a problem into code - even with little code of your own - you stumble across all the questions that developers usually ask. Suddenly there are these little special cases that weren't even on your mind before. Suddenly you realize that a term like "consumed" is not at all clear - does it mean commissioned, billed or already paid? And suddenly you realize that a seemingly simple decision actually entails half a dozen dependencies.
This new change of perspective made a lasting impression on me. These days I have come to understand better why developers are sometimes so insistent when it comes to precise definitions, and why a small change is often not small at all. It's a bit like switching to the other side of the desk: you feel the loss of friction, the detailed work, the weighing up - and this gives you a much clearer view of what happens on a day-to-day basis.
Of course, Cursor was a great help. I didn't actually write a single line of code myself in this project, but only "discussed" it with Cursor. The editor took my descriptions in natural language, made suggestions, generated and adapted code. This is how the app was created step by step - without me having to type it myself. This was exciting because it allowed me to concentrate much more on the logic and requirements rather than on the syntax or details of the programming language.
The limits of tinkering
But there are also limits to "tinkering", e.g. in the area of authentication. It was clear to us from the outset that we would use the internal Keycloak service. There are no experiments, no shortcuts, no tinkering solutions. Authentication is a core system that has to be stable, secure and verifiable. This was a valuable contrast for me: on the one hand, the playful, fast handling of low-code approaches, and on the other, the need for clear, fixed services. For me, the opportunity lies precisely in this balance: companies can create a stable basis - identity, logging, data platforms - and allow a flexible layer of experimentation on top.
And this is precisely where I see a crucial point: in order for such experiments to emerge at all, there needs to be conscious enablement within the company. Giving your employees the opportunity to try things out within clear guidelines opens up a huge space for creativity and learning processes. When the basic architecture is stable and the playing field is clearly defined, ideas suddenly emerge that would never have been seen in traditional project settings. This is exactly where we support companies: building this stable foundation in such a way that it provides security - and at the same time leaves room to try out new things.
Specialist: Keycloak
Our specialists will support you from the beginning to the end of your Keycloak project and will assist you with their many years of experience and expertise. Even after successful implementation, our specialists are at your disposal for ongoing operation, adjustments, further developments and training.Our specialists offer youConsulting & conceptionMigration & integrationCustomizingOperationFurther developmentWorkshops & training (remote or on-site)
More about authentication
What remains after this experiment? Above all, a changed understanding of roles and processes. I can formulate requirements more precisely because I have felt for myself where the stumbling blocks lie. I have experienced that prototypes make discussions concrete and avoid misunderstandings. And I have learned how much respect the actual craft deserves: clean code, well thought-out architecture, patient detail work.
Such small apps can be useful in very different areas. They help to improve your own workflows, simplify analyses or optimize business processes on a small scale. But as with all software, the real work begins when the app is used: How often does the app need to receive security updates? What happens with user feedback? Who steps in if the app suddenly stops working? Once an app is running on the server, it is far from being truly "productive". That's why we've set ourselves internal guidelines here too - and as always: you build it, you run it. However, this also means that these little helpers can disappear just as quickly as they were created. And that's perfectly fine - as long as they create real added value in the meantime.
But there are also risks. Managers who build their own apps run the risk of getting bogged down. It's easy to think an app is "almost finished" because the surface looks pretty - and overlook the fact that there are still whole layers missing underneath. Without guard rails, shadow IT quickly emerges that nobody wants to maintain. And last but not least, it is important to keep the roles clear: A managing director remains a managing director, even if they write a few lines of code from time to time.
Conclusion
Nevertheless, the experiment was worthwhile for me. It changed my conversations with the team, sharpened my view of architecture and showed me how important it is to open up spaces for experimentation without jeopardizing the foundation. I won't suddenly become a developer again - but I have taken something with me that makes my job as Managing Director better.
And perhaps that is precisely the most important insight: it's not about being able to do everything yourself. It's about understanding what happens when others do it - and creating the right structures so that your own team can also try things out, learn and grow.
